[SeaBIOS] Saving a few bytes across a reboot

[Stefan Berger]

On 02/08/2018 10:52 AM, Marc-André Lureau wrote:
> Hi
>
> On Wed, Feb 7, 2018 at 6:21 PM, Laszlo Ersek <lersek at 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
>