<div dir="ltr">Hi,<br><br>I'm trying to get my head fully wrapped around SBAT, and have a question<br>about the SbatLevel UEFI variable which contains SBAT revocation<br>data. If I'm understanding [1] correctly, the idea is that we can add<br>SBAT data without a firmware update by using a signed UEFI variable. The<br>variable would be written with the<br>EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute, which<br>would ensure that updates to the variable are signed by the same cert<br>and that the timestamp of the updated data is higher than what was there<br>before to prevent rollback.<br><br>My assumption from the above was that some authority like Microsoft or<br>Redhat or <a href="http://uefi.org">uefi.org</a> would be in charge of maintaining the latest SBAT<br>data and producing signed updates, which would then be placed in the<br>shim git repo as a binary blob to be embedded in the binary at build<br>time.<br><br>But currently it looks like when the SbatLevel variable is set at [2] it<br>uses SBAT_VAR_ATTRS, which is currently UEFI_VAR_NV_BS rather than<br>UEFI_VAR_NV_BS_TIMEAUTH [3]. Is the plan to switch to TIMEAUTH at some<br>point? If so, what's holding it back? If not, why not?<br><br>-Nicholas<br><br>[1]: <a href="https://github.com/rhboot/shim/blob/main/SBAT.md#generation-based-revocation-overview">https://github.com/rhboot/shim/blob/main/SBAT.md#generation-based-revocation-overview</a><br>[2]: <a href="https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/sbat.c#L367">https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/sbat.c#L367</a><br>[3]: <a href="https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/include/sbat.h#L33">https://github.com/rhboot/shim/blob/e5bf2ba744731646749b605a322c353011f93c8e/include/sbat.h#L33</a><br></div>