[SeaBIOS] Saving a few bytes across a reboot

Laszlo Ersek lersek at redhat.com
Wed Feb 7 18:21:01 CET 2018

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.

>> Again, we have to see where the barrier is, between OS and firmware, or
>> between OS-level users:
>> - In both cases, 3rd party UEFI apps / driver are considered equally
>>    privileged to the OS kernel;
>> - in the OS<->firmware barrier case, SMM is required, and UEFI apps and
>>    the OS kernel are similarly restricted to submitting requests to SMM,
>>    and all the business verification belongs in SMM,
> So SMM can verify whether the parameters it gets are valid. Whether now
> the user wanted to set operation 0 but the ACPI code submitted 5 (Clear
> TPM), would be a matter of verifying the ACPI code that's in-between. Is
> an attack via ACPI manipulation through some UEFI module possible?

Yes, it is possible.

There are dedicated UEFI (and PI -- "platform init") services for
installing new ACPI tables, and even for locating and parsing -- albeit
in a *very* cumbersome way -- existing ACPI tables (AML too). Once the
right ACPI objects are found, they can be overwritten.

> On the OS level it must remain a privileged operation of an admin to
> issue these PPI codes. That it is a privileged operation is implemented
> by the OS and I don't think we need to do anything. What we would want
> to prevent is abuse by a module that the firmware executes for example.
> I think this is the driving force for a UEFI variable and the fact that
> it's being locked (and later on unlocked so SMM mode can write to it ?)

This unlocking intrigues me. Assuming it happens in SMM, I have no idea
how the implementation tells apart the requestors (3rd party UEFI app
vs. OS).

> As for the use case, I would say it's automation on the OS level. From
> that perspective it's support could probably be deferred, which may
> eliminate at least the SMM part. However, UEFI uses the PPI mechanisms
> itself to issue certain commands when interacting with its menu. I am
> not sure whether SMM code is involved here... but for being able to use
> UEFI and TPM 2 at least for the UEFI support the PPI part needs to be
> there, otherwise the menu items one gets won't do anything. [The
> question is does UEFI execute ACPI or write directly in the UEFI
> varaible? My guess is the latter.]

I'm sorry, I'm out of my depth here. Can we re-have this discussion on
edk2-devel? (A bit later though, please, because currently I'm unable to
send email to edk2-devel. The 01.org list server recently dislikes
something about my emails and keeps rejecting them.)

>> (Sorry if this email is too long and confusing! I'm confused.)
> Me too. I am not clear on specifics in UEFI, such as memory protections
> setup while a module is running in UEFI. Is NVRAM protected from
> overwrite?

Only SMRAM and pflash (aka NVRAM aka UEFI variables, on QEMU anyway) are
protected from direct hardware write.

Whether the write to SMRAM/pflash hardware comes from the OS or a 3rd
party UEFI app is irrelevent, both are prevented; only code running in
SMM is permitted write access.

Furthermore, it is irrelevant whether the OS or a 3rd party UEFI app is
the one that submits a request into SMM. If the request buffer passes
validation, then SMRAM and/or pflash (as appropriate) are updated. This
is to say that only the *data* in the request determine success vs.
failure; the "origin" of the request is unprovable and means nothing.

> Who can run a module in UEFI?

If you have write access to the EFI system partition, or can plug a PCI
card in the system, you can run UEFI code (dependent on Secure Boot and
signing the UEFI binary).

> Does it need to be signed ?

It depends on the SB configuration, but either way, a correct signature
does not grant access to SMRAM or pflash. Just because SB allows a
binary to be executed, the binary still has to submit a valid request
buffer to SMM, for modifying SMRAM or pflash.


More information about the SeaBIOS mailing list