Hi On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger <[email protected]> wrote: > On 02/08/2018 10:52 AM, Marc-André Lureau wrote: >> >> Hi >> >> On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek <[email protected]> wrote: >>> >>> On 02/07/18 17:44, Stefan Berger wrote: >>>> >>>> On 02/07/2018 10:50 AM, Laszlo Ersek wrote: >>>>> >>>>> OK, but if the OS is allowed to modify this set of "queued operations", >>>>> then what protection is expected of SMM? Whether you can modify the TPM >>>>> directly, or queue random commands for it at libery, what's the >>>>> difference? >>>> >>>> >>>> On the OS level it is presumably an operation that is reserved to the >>>> admin to queue the operation. >>>> >>>> I am not that familiar with UEFI and who is allowed to run code there >>>> and what code it can execute. But UEFI seems to lock the variable that >>>> holds that PPI code that tells it what to do after next reboot. So >>>> presumably a UEFI module cannot modify that variable but can only read >>>> it (and hopefully not manipulate NVRAM directly). If PPI was implemented >>>> through a memory location where the code gets written to it could do >>>> that likely easily (unless memory protections are setup by UEFI, which I >>>> don't know), cause a reset and have UEFI execute on that code. >>> >>> This makes sense... but then it doesn't make sense :) >>> >>> Assume that the variable is indeed "locked" (so that random UEFI drivers >>> / apps cannot rewrite it using the UEFI variable service). Then, >>> >>> - if the lock is enforced in SMM, then the variable will be locked from >>> the OS as well, not just from 3rd party UEFI apps, so no PPI >>> operations can ever be queued, >>> >>> - if the lock is "simulated" in ACPI or in non-SMM firmare code (= in >>> the "runtime DXE driver" layer), then the lock can be circumvented by >>> both 3rd party UEFI apps and the OS. >> >> >> Regarding security of PPI pending operations, the spec clearly says >> "The location for tracking the pending PPI >> operation, including the tracking of necessary PLATFORM RESET >> operations, does not need to be a secure or trusted location." (9.9 >> p.32) >> >> I assume this is because the user has to confirm the pending operation >> in pre-os console, so if some attacker wanted to clear the TPM, the >> user would have to confirm it (same for other operation of flags >> manipulation). That may not be the best security design, but at least, >> the user could be in control. > > > I had not read that - at least not recently. > There are operations that eliminate the future prompt (operation 18) but > these require at least a one-time interaction. Though the flag that causes > the prompt needs to be protected so that some software cannot just modify it > and cause a clear without user interaction. In UEFI this is solved (hope) > with the locking of the variable. In a BIOS one could store it in a TPM > NVRAM location that has access restrictions that can only be fulfilled by > the firmware.
Or it could be stored in the "PPI qemu device" you proposed, couldn't it? The firmware could lock the access to some PPI memory after a PPI phase. That may not be as secure as SMM variable lock service in UEFI, but that would be more portable and probably easier to implement. >> How does the UEFI runtime variable services verify the authenticity of >> the requests? Or does it only check a request validity? > > > Afaics it only checks whether the request has valid parameters, not where it > comes from. Then I don't see much point yet going through SMM to set the pending operations (protecting the result could eventually be good though). -- Marc-André Lureau _______________________________________________ SeaBIOS mailing list [email protected] https://mail.coreboot.org/mailman/listinfo/seabios
