Message-ID: <2023071643-broiler-level-afbf@gregkh>
Date:   Sun, 16 Jul 2023 20:28:10 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Luca Boccassi <bluca@...ian.org>
Cc:     Daniel P. Berrangé <berrange@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>, lennart@...ttering.net,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@...uxfoundation.org> 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@...uxfoundation.org> 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.

And that is the disconnect.  To think that this magic "security canary
number" is somehow not going to affect my work is not correct.  See
below for details...

> > > > > > 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.

Great, so who will be doing this process work?

Seriously, we have to know this before we could accept this type of
thing.  To not do so would mean this value means nothing.

> > > > > > 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?

And who will be sending that to me?  For what releases?  For how long
will they be agreeing to do this work for?  How will it be tracked?
What will they be using to determine when the number will be changed?
How will they know it should be changed?

None of this has been answered, and that's the real issue here.  This
"magic number" is saying it is going to reflect some specific "security
issue" yet no one is saying how those issues are going to be determined,
or anything else about it.

Again, as I've repeated numerous times, tell us how often this number
would have changed in the past X years to give us an idea of how you
will be changing it going forward.  To not provide any of this means
this patch adding this magic number means nothing as no one knows what
it actually means.

thanks,

greg k-h

Powered by blists - more mailing lists