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.