Message-ID: <5e7716de-ffce-e89d-0aa3-45eed4804652@redhat.com>
Date:   Thu, 13 Jul 2023 22:49:31 +0200
From:   Emanuele Giuseppe Esposito <eesposit@...hat.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        bluca@...ian.org, lennart@...ttering.net,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Daniel P. Berrangé <berrange@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage



Am 13/07/2023 um 18:58 schrieb Greg KH:
> On Thu, Jul 13, 2023 at 05:51:57PM +0200, Vitaly Kuznetsov wrote:
>> Greg KH <gregkh@...uxfoundation.org> 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"?


As I wrote you privately before, yeah I think there is a
misunderstanding here. I always thought that RFC stands for "hey I don't
know what I am doing, can you help me?". I apologize for the
misunderstanding.
Also other hints were "*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."
and "Issues with this patch:" section.

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

Wow, I was not aware of these policies O.O.
What you say makes sense, but what about developers not working in a
company? Then they are completely ignored?
Otherwise a simple way to trick you is to actually use my gmail address
and you won't ever know that I work for RH.
Is this the policy of the community? If so, is it explained clearly
somewhere? Because I think a lot of people need to be aware of this, not
wait that this mess happens for every company employer submitting a
patch in the kernel.

> 
> 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 :)

Glad to be the one that opened the pandora box for everyone :)

Thank you,
Emanuele
> 
> thanks,
> 
> greg k-h
> 

Powered by blists - more mailing lists