From: Greg KH <gregkh@linuxfoundation.org>
To: Emanuele Giuseppe Esposito <eesposit@redhat.com>
Cc: x86@kernel.org, "Thomas Gleixner" <tglx@linutronix.de>,
bluca@debian.org, lennart@poettering.net,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"Dave Hansen" <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Alexander Potapenko" <glider@google.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Vitaly Kuznetsov" <vkuznets@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
Date: Wed, 12 Jul 2023 17:45:58 +0200 [thread overview]
Message-ID: <2023071237-private-overhang-7f86@gregkh> (raw)
In-Reply-To: <20230711154449.1378385-1-eesposit@redhat.com>
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.
As is, this is not going to go far.
thanks,
greg k-h
next prev parent reply other threads:[~2023-07-12 15:46 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-11 15:44 [RFC PATCH v2] x86/boot: add .sbat section to the bzImage Emanuele Giuseppe Esposito
2023-07-12 1:21 ` H. Peter Anvin
2023-07-12 1:33 ` H. Peter Anvin
2023-07-12 6:19 ` Emanuele Giuseppe Esposito
2023-07-12 12:00 ` Borislav Petkov
2023-07-12 12:48 ` Daniel P. Berrangé
2023-07-12 13:28 ` Borislav Petkov
2023-07-12 14:06 ` Daniel P. Berrangé
2023-07-12 15:43 ` Greg KH
2023-07-12 16:23 ` Luca Boccassi
2023-07-12 16:57 ` Greg KH
2023-07-12 18:59 ` Luca Boccassi
2023-07-12 19:05 ` Greg KH
2023-07-12 19:35 ` Luca Boccassi
2023-07-12 19:42 ` Borislav Petkov
2023-07-12 19:56 ` Luca Boccassi
2023-07-12 20:01 ` Borislav Petkov
2023-07-12 20:16 ` Luca Boccassi
2023-07-12 20:07 ` Greg KH
2023-07-12 20:41 ` Luca Boccassi
2023-07-12 21:11 ` Greg KH
2023-07-12 21:12 ` Willy Tarreau
2023-07-12 22:32 ` Luca Boccassi
2023-07-12 21:20 ` Greg KH
2023-07-12 21:50 ` Luca Boccassi
2023-07-13 6:09 ` Greg KH
2023-07-14 0:29 ` Luca Boccassi
2023-07-15 6:51 ` Greg KH
2023-07-16 17:41 ` Luca Boccassi
2023-07-16 18:28 ` Greg KH
2023-07-17 9:22 ` Daniel P. Berrangé
2023-07-17 11:06 ` Peter Zijlstra
2023-07-17 11:47 ` Daniel P. Berrangé
2023-07-17 14:10 ` Greg KH
2023-07-17 11:12 ` Luca Boccassi
2023-07-17 14:11 ` Greg KH
2023-07-17 14:06 ` Greg KH
2023-07-12 15:45 ` Greg KH [this message]
2023-07-13 8:57 ` Vitaly Kuznetsov
2023-07-13 9:16 ` Peter Zijlstra
2023-07-13 14:58 ` Greg KH
2023-07-13 15:51 ` Vitaly Kuznetsov
2023-07-13 16:58 ` Greg KH
2023-07-13 20:49 ` Emanuele Giuseppe Esposito
2023-07-13 22:04 ` Greg KH
2023-07-14 6:57 ` Emanuele Giuseppe Esposito
2023-07-15 6:59 ` Greg KH
2023-07-13 13:33 ` Ard Biesheuvel
2023-07-13 13:52 ` Ard Biesheuvel
2023-07-13 20:39 ` Emanuele Giuseppe Esposito
2023-07-13 22:31 ` Luca Boccassi
2023-07-14 8:52 ` Ard Biesheuvel
2023-07-14 9:13 ` Matthew Garrett
2023-07-14 9:14 ` Ard Biesheuvel
2023-07-14 9:25 ` Luca Boccassi
2023-07-17 16:08 ` James Bottomley
2023-07-17 16:56 ` Daniel P. Berrangé
2023-07-17 17:15 ` James Bottomley
2023-07-17 18:16 ` Daniel P. Berrangé
2023-07-20 16:46 ` Eric Snowberg
2023-07-20 17:07 ` James Bottomley
2023-07-20 18:10 ` Eric Snowberg
2023-07-20 19:16 ` Luca Boccassi
2023-07-21 0:02 ` Eric Snowberg
2023-07-21 8:55 ` Luca Boccassi
2023-07-21 11:24 ` James Bottomley
2023-07-21 12:40 ` Luca Boccassi
2023-07-21 13:01 ` James Bottomley
2023-07-21 13:10 ` Luca Boccassi
2023-07-21 13:33 ` James Bottomley
2023-07-21 15:14 ` Luca Boccassi
2023-07-21 15:22 ` Luca Boccassi
2023-07-21 15:27 ` James Bottomley
2023-07-13 23:13 ` Luca Boccassi
2023-07-14 9:33 ` Ard Biesheuvel
2023-07-14 9:59 ` Daniel P. Berrangé
2023-07-14 10:40 ` Luca Boccassi
2023-07-18 13:34 ` Paolo Bonzini
2023-07-18 14:02 ` Luca Boccassi
2023-07-18 15:51 ` Paolo Bonzini
2023-07-18 16:35 ` Daniel P. Berrangé
2023-07-19 13:21 ` Paolo Bonzini
2023-07-19 13:34 ` Luca Boccassi
2023-07-19 15:11 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023071237-private-overhang-7f86@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=berrange@redhat.com \
--cc=bluca@debian.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eesposit@redhat.com \
--cc=glider@google.com \
--cc=hpa@zytor.com \
--cc=lennart@poettering.net \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mingo@redhat.com \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox