Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Greg KH <gregkh@linuxfoundation.org> writes:

> On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe Esposito wrote:
>> *Important*: this is just an RFC, as I am not expert in this area and
>> I don't know what's the best way to achieve this.
>> 
>> v2:
>> * add standard "sbat,1,SBAT Version,..." header string
>> 
>> The aim of this patch is to add a .sbat section to the linux binary
>> (https://github.com/rhboot/shim/blob/main/SBAT.md).
>> We mainly need SBAT in UKIs (Unified Kernel Images), as we might want
>> to revoke authorizations to specific signed PEs that were initially
>> considered as trusted. The reason might be for example a security issue
>> related to a specific linux release.
>> 
>> A .sbat is simply a section containing a string with the component name
>> and a version number. This version number is compared with the value in
>> OVMF_VARS, and if it's less than the variable, the binary is not trusted,
>> even if it is correctly signed.
>> 
>> Right now an UKI is built with a .sbat section containing the
>> systemd-stub sbat string (upstream + vendor), we would like to add
>> also a per-component specific string (ie vmlinux has its own sbat,
>> again upstream + vendor, each signed add-on its own and so on).
>> In this way, if a specific kernel version has an issue, we can revoke
>> it without compromising all other UKIs that are using a different
>> kernel with the same stub/initrd/something else.
>> 
>> Issues with this patch:
>> * the string is added in a file but it is never deleted
>> * if the code is not modified but make is issued again, objcopy will
>>   be called again and will fail because .sbat exists already, making
>>   compilation fail
>> * minor display issue: objcopy command is printed in the make logs
>> 
>> Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
>> ---
>>  arch/x86/boot/Makefile | 3 +++
>>  1 file changed, 3 insertions(+)
>> 
>> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
>> index 9e38ffaadb5d..6982a50ba0c0 100644
>> --- a/arch/x86/boot/Makefile
>> +++ b/arch/x86/boot/Makefile
>> @@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
>>  
>>  $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
>>  	$(call if_changed,image)
>> +	@$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat
>> +	@$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat;
>
> Who controls "linux.org"?  Why are you thinking they have anything to do
> with kernel development?
>
> This shows a huge lack of understanding of loads of things, please go
> get other experienced Red Hat developers to sign off on the next version
> of your patch before you ask the community to review it.

FWIW,

this was an RFC to answer a fairly straitforward question: is upstream
Linux interested in / is a suitable place for having SBAT revocation
mechanism or not. We can, of course, iron out the details whether it
should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
"linux.onion" and where to put objcopy call, whether to silence its
output or not but these are rather implemntation details. I don't
particularly see why anyone would need to get additional sign-offs to
just ask a question (which I don actually think was asked before!) and
IMO an RFC/patch is usually the best way to do so.

Following the discussion, it seems that at least x86 maintainer[s] are
opposed to the very idea of having SBAT revocation mechanism integrated
upstream because it's hard to meaningfully define what epoch is. This is
OK (which doesn't mean we all agree to that) but as there's real need to
revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
come up with their custom, downstream only ways to do it. Without an
upstream reference, however, they may come up with very differently
looking SBAT sections, this may or may not be problematic in the future,
who knows.

-- 
Vitaly