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

[Luca Boccassi]

On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jul 14, 2023 at 01:29:20AM +0100, Luca Boccassi wrote:
> > On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > > > Who is going to be responsible for determining that this number needs to
> > > > > be updated?
> > > >
> > > > Most likely those who understand the problem space - largely the group
> > > > of people maintaining the EFI stack, with various inputs, I imagine.
> > > > That's how it currently works for various bootloaders.
> > >
> > > We need specifics and to have people agree to do this, otherwise, again,
> > > this patch is useless.
> >
> > Not really, as this is about mechanism, not process.
>
> And this right here is why everyone is both so mad at this patch from
> our side, and so confused about patch from the developer's side.
>
> To think that "let's add a security canary to the kernel image" is
> anything other than a process issue, shows a lack of understanding about
> exactly how the kernel is released, how the existing kernel security
> response team works, and who does any of this work.  To ignore that
> means that there is no way in the world this can ever be accepted.

This _question_ was about mechanism, not process. As already
mentioned, nobody asked you to sign up for any extra work.

> > > > > What is their response time?
> > > > >
> > > > > Who will they be submitting the patch to this string in order to have it
> > > > > change?
> > > >
> > > > A bit too soon for exact details on processes given where we are, I think.
> > >
> > > Not at all, this is a proposal for a "security flag" for the kernel,
> > > getting this all decided now is the only correct way to determine if
> > > this is actually something that can work properly.
> >
> > No, the question here was about mechanism and storage. And it already
> > works btw, it's just the kernel that's lagging behind, as usual.
>
> Perhaps this is on purpose as many of us consider this type of thing
> nothing more than "security theatre" that will not work for a project
> like ours?

Yep, blacklotus and boothole were just security theatre, sounds about right.

> > > To just go "we are going to randomly add a number that will sometimes be
> > > incremented in the future to determine the buggyness of the kernel
> > > without saying who will control this, or how it will be done" is crazy.
> > >
> > > Would other operating systems or projects accept such a change without
> > > this information?
> > >
> > > Would you take this patch if you were responsible for kernel releases?
> >
> > I think you are still missing one tiny bit of information: it is
> > already used in other projects
> >
> > $ sudo objcopy -O binary --only-section=.sbat
> > /boot/efi/EFI/Debian/grubx64.efi /dev/stdout
> > sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
> > grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
> > grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2
>
> Nice, and what describes the process that the grub team uses to set that
> number?  Where is that document and team that does this work?

At the link that was pasted dozens of times already, including in that output:

https://github.com/rhboot/shim/blob/main/SBAT.md

> And frankly, grub is nothing more than a tiny project compared to the
> kernel, with the huge majority of the world's users of Linux not even
> using grub at all.  So of course the use of grub for this might just be
> a bit different as to how Linux should be using it.

No, it's identical, because as it was already said a million times
this is about the 3rd party CA + Shim flow (which is the only flow
that works by default on consumer grade x86 machines and thus it's
what all the major distributions use), and in that flow there is
always Shim, and there is always Grub, and there is always Linux, so
the ratio is 1:1:1.
Outside of this use case, this doesn't apply and doesn't affect
anything, it's a no-op.

> > > > > How long will this feature have to be maintained?
> > > >
> > > > Until something else supplants EFI, I'd imagine
> > >
> > > So 40+ years, great, who is going to fund that?
> >
> > Who funds EFI work?
>
> UEFI the spec is funded by various companies (Intel, et-all).  So you
> are saying that these companies also need to do this development too?
> Have you got them to agree to this?  If so, great, let's get their
> signed-off-by on it please.
>
> Otherwise you all are saying "someone else will do all of this process
> work", which frankly, is totally insulting to those of us who _do_ do
> all of the process work for security issues and kernel releases.

Nobody asked you to do any process work.

> > > > > We have a plethora of kernel changes in our history to learn from here,
> > > > > please do so and show how this will affect us going forward based on our
> > > > > past, otherwise we have no way of knowing how any of this is going to
> > > > > work.
> > > >
> > > > I am not aware of anything similar enough, but please do point those
> > > > out if you are.
> > >
> > > Audit our past history and document when the number would have changed
> > > please.
> >
> > Sure, where do I send the invoice?
>
> If you are not willing to take the time to determine how this proposed
> change will affect the kernel developers and infrastructure by doing
> some modeling based on our past history, then we have no reason to even
> consider accepting this change as you are stating that you have no idea
> how it will affect us.

There's no need for that to tell you how this will affect you: it will
not. Every now and then you'll receive a one-liner patch to apply.
What's so terrible about that?