[SeaBIOS] Saving a few bytes across a reboot

[Marc-André Lureau]

Hi

On Thu, Feb 8, 2018 at 5:35 PM, Stefan Berger
<stefanb at 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 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.

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