On 01/07/16 02:01, Jordan Justen wrote: > On 2016-01-06 13:19:08, Laszlo Ersek wrote: >> Change the image verification policy for option ROM images to 0x00 >> (ALWAYS_EXECUTE). >> >> While this may not be a good idea for physical platforms (see e.g. >> <https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem >> to outweigh the drawbacks: >> >> - For QEMU's virtual PCI devices, and for some assigned PCI devices, the >> option ROMs come from host-side files, which can never be rewritten from >> within the guest. Since the host admin has full control over a guest >> anyway, executing option ROMs that originate from host-side files >> presents no additional threat to the guest. >> > > I wonder if we could somehow allow only option ROMs read from the host > disk to be trusted without being signed. (Maybe a set of image hashes > could be stored into fw_cfg?)
The by-the-book way would be to generate host-specific (or local organization-specific) certificates, enroll them in the guest(s), and sign the oproms in question with these certs. > I also wonder if someday these images might be able to be signed... Although I've never tried, I believe the above should be technically possible right now. The problem remains the same old "cert management and enrollment" one. I have no clue if and when distros would be willing to sign oproms (and with what keys). Plus that wouldn't address personal iPXE builds. With regard to host- or local org-specific keys, UEFI 2.5 introduced AuditMode and DeployedMode for Secure Boot. I believe these should enable the development of runtime OS utilities that handle key enrollment -- not just for boot applications, but also for drivers. Once such "uniform" utilities exist (and sysadmins can "trivially" enroll firmware keys from within their usual environments), we might be able to flip this PCD back to 0x04, and require users to sign all oproms they want to launch (and to enroll those keys). Until such utilities exists for *drivers* (cf. shim / MOK for boot applications!), I think it's unreasonable to place such a requirement. > > Anyway, for both patches: > > Reviewed-by: Jordan Justen <[email protected]> Thanks! I'll go ahead and commit this series soon. Cheers Laszlo > >> - For assigned physical PCI devices with option ROMs, the argument is not >> so clear-cut. In theory a setup could exist where: >> >> - the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION) >> rejects the option ROM of a malicious physical PCI device, but >> >> - when the device is assigned to the guest, OVMF executes the option ROM >> in the guest, >> >> - the option ROM breaks out of the guest (using an assumed QEMU >> vulnerability) and gains QEMU user privileges on the host. >> >> However, in order to escalate as far as it would happen on the bare >> metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access >> on the host), the malicious option ROM would have to break through (1) >> QEMU, (2) traditional UID and GID based privilege separation on the >> host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware >> boundary. This is not impossible, but not likely enough to discourage >> the use cases below. >> >> - This patch makes it possible to use unsigned iPXE network drivers that >> QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV >> VFs, even if Secure Boot is in User Mode or Deployed Mode. >> >> - The change also makes it possible to execute unsigned, outdated >> (revoked), or downright malicious option ROMs of assigned physical >> devices in guests, for corporate, entertainment, academia, or security >> research purposes. >> >> Cc: Paolo Bonzini <[email protected]> >> Cc: Gerd Hoffmann <[email protected]> >> Cc: Jordan Justen <[email protected]> >> Cc: Chao Zhang <[email protected]> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Laszlo Ersek <[email protected]> >> --- >> OvmfPkg/OvmfPkgIa32.dsc | 4 ++++ >> OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++++ >> OvmfPkg/OvmfPkgX64.dsc | 4 ++++ >> 3 files changed, 12 insertions(+) >> >> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc >> index afde345..62065f7 100644 >> --- a/OvmfPkg/OvmfPkgIa32.dsc >> +++ b/OvmfPkg/OvmfPkgIa32.dsc >> @@ -404,6 +404,10 @@ [PcdsFixedAtBuild] >> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 >> !endif >> >> +!if $(SECURE_BOOT_ENABLE) == TRUE >> + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 >> +!endif >> + >> # IRQs 5, 9, 10, 11 are level-triggered >> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 >> >> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc >> index 2cbd417..d0ff2bb 100644 >> --- a/OvmfPkg/OvmfPkgIa32X64.dsc >> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc >> @@ -410,6 +410,10 @@ [PcdsFixedAtBuild.X64] >> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 >> !endif >> >> +!if $(SECURE_BOOT_ENABLE) == TRUE >> + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 >> +!endif >> + >> # IRQs 5, 9, 10, 11 are level-triggered >> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 >> >> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc >> index 309b5e2..b848976 100644 >> --- a/OvmfPkg/OvmfPkgX64.dsc >> +++ b/OvmfPkg/OvmfPkgX64.dsc >> @@ -409,6 +409,10 @@ [PcdsFixedAtBuild] >> gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 >> !endif >> >> +!if $(SECURE_BOOT_ENABLE) == TRUE >> + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 >> +!endif >> + >> # IRQs 5, 9, 10, 11 are level-triggered >> gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 >> >> -- >> 1.8.3.1 >> _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
