What's the plan for signing SbatLevel?

[Nicholas Bishop]

Hi,

I'm trying to get my head fully wrapped around SBAT, and have a question
about the SbatLevel UEFI variable which contains SBAT revocation
data. If I'm understanding [1] correctly, the idea is that we can add
SBAT data without a firmware update by using a signed UEFI variable. The
variable would be written with the
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute, which
would ensure that updates to the variable are signed by the same cert
and that the timestamp of the updated data is higher than what was there
before to prevent rollback.

My assumption from the above was that some authority like Microsoft or
Redhat or uefi.org would be in charge of maintaining the latest SBAT
data and producing signed updates, which would then be placed in the
shim git repo as a binary blob to be embedded in the binary at build
time.

But currently it looks like when the SbatLevel variable is set at [2] it
uses SBAT_VAR_ATTRS, which is currently UEFI_VAR_NV_BS rather than
UEFI_VAR_NV_BS_TIMEAUTH [3]. Is the plan to switch to TIMEAUTH at some
point? If so, what's holding it back? If not, why not?

-Nicholas

[1]:
https://github.com/rhboot/shim/blob/main/SBAT.md#generation-based-revocation-overview
[2]:
https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/sbat.c#L367
[3]:
https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/include/sbat.h#L33
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.einval.com/pipermail/efi/attachments/20211018/f27fe3a1/attachment.htm>