On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
Hi
On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek lersek@redhat.com 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.
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.
thanks
Hi
On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger stefanb@linux.vnet.ibm.com wrote:
On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
Hi
On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek lersek@redhat.com 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 -
Stefan Berger