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

[Greg KH]

On Thu, Jul 13, 2023 at 05:51:57PM +0200, Vitaly Kuznetsov wrote:
> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> > On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
> >> 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.
> >
> > Again, no questions were asked.
> >
> > And when I asked questions, no one knowledgable answered them (hint, we
> > release more than 3 kernels a year...)
> >
> 
> I think that getting these questions was actually the main reason to
> send out the RFC. (Personally, I don't think that stable@ is an
> insurmountable problem with an epoch-based revocation mechamism as we
> can e.g. switch module name from "linux" to e.g. "linux-stable-5.14"
> when screating a stable branch or do something like that but that's not
> the main/only problem we see here).

There was no "questions" asked about this RFC, so what should we respond
with except with what we did, "No way this is acceptable, as this was
not thought through at all"?

> > Turn it around, what would you do if you got this patch in your inbox to
> > review and you were responsible for doing kernel releases and security
> > fixes?
> >
> 
> I replied to the thread not to defend the idea as after the discussion
> it is clear there's a lot to take into consideration if anyone decides
> to pursue the SBAT idea ever again (and the discussion is now well
> preserved in the archive!). I replied to disagree with "get sign-offs
> from senior people before sending RFCs" idea, I believe that asking
> questions by sending a not-fully-ready patch as "RFC" should not be
> discouraged. 

On the contrary, this is EXACTLY what needs to happen here.

This developer (I'm not picking on them at all, it's not their fault),
should be taking advantage of the resources of their company when
dealing with core, critical, functionality of the kernel.

To just "throw them at the wolves" like Red Hat did, is a total
disservice to them, AND it wastes the time and resources of the
community, as it is not our job to train and teach them, it is the job
of the senior people at your company to do so.

We have a non-zero number of companies that right now who are in the
"penalty box" because their developers have had a history of throwing
crud over the wall, or having inexperienced developers submit changes
that are obviously wrong, which waste the time and energy of the kernel
community.  For companies that do this, we have instituted the
requirement that they get review and acceptance of kernel changes from
the experienced developers within the company BEFORE submitting their
changes to the community, for the basic fact that this actually saves
EVERYONE time and energy.

It allows the developer to grow and learn more quickly, it saves the
energy and time of the reviewers (which is our most valuable resource
right now) and it provides a solid path forward on the corporate ladder
of using mentors well, and lifting up your own employees.

I don't think you want us to put Red Hat into this type of policy at
this point in time, but if you all keep insisting that you can just "let
loose" inexperienced developers who wish to change the core
functionality of how we operate, that can easily change.

Remember, this proposed patch directly affects how the kernel is
released, how the security team works, and how the security of Linux is
viewed by the world.  Why would you NOT want your experienced developers
to review such a thing first?  To not want that, means that Red Hat just
doesn't care about their developers, nor the community, which I sure
hope is not the case.

So again, yes, I am INSISTING that the next version of this change be
properly reviewed, vetted, and signed-off-by, by the senior kernel
developers at your company BEFORE you submit it again for review by
anyone in the community.  Only that way can I hope that it will be
something that actually takes into account all of the questions we have
already had for this proposed 2 line change.

Funnily, I think this proposed patch takes the dubious record for "most
innocuous looking patch that will directly affect the development
procedures for the most people", an outstanding record that I hope never
gets broken :)

thanks,

greg k-h