This is more of question/discussion than an issue - feel free to close it if there is a better forum for discussions.
When utilizing the build.sh script to compile OVMF, the "OvmfPk/OvmfPkgX64.dsc" package is used.
This firmware can be used to boot a VM in which tools like "snpguest" can be run to produce attestation reports.
My understanding is that only the virtual firmware (OVMF, in this case) is measured/attested and not kernel/initrd/kernel command line/etc. With something like the "OvmfPkg/AmdSev/AmdSevX64.dsc" package or an OMVF that enforces secure boot with a hard coded trust store, this measurement/validation could delegated to the firmware.
This leads me to my question: in what way does the OVMF.fd produced by the build script contribute to the confidentiality of a guest? In other words, what is the value of measuring firmware if we can't validate the integrity of the operating system?
Perhaps I've misunderstood something - feel free to enlighten me!
This is more of question/discussion than an issue - feel free to close it if there is a better forum for discussions.
When utilizing the build.sh script to compile OVMF, the "OvmfPk/OvmfPkgX64.dsc" package is used. This firmware can be used to boot a VM in which tools like "snpguest" can be run to produce attestation reports.
My understanding is that only the virtual firmware (OVMF, in this case) is measured/attested and not kernel/initrd/kernel command line/etc. With something like the "OvmfPkg/AmdSev/AmdSevX64.dsc" package or an OMVF that enforces secure boot with a hard coded trust store, this measurement/validation could delegated to the firmware.
This leads me to my question: in what way does the OVMF.fd produced by the build script contribute to the confidentiality of a guest? In other words, what is the value of measuring firmware if we can't validate the integrity of the operating system?
Perhaps I've misunderstood something - feel free to enlighten me!