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

[Vitaly Kuznetsov]

Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:

> On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:
>> FWIW,
>> 
>> this was an RFC to answer a fairly straitforward question: is upstream
>> Linux interested in / is a suitable place for having SBAT revocation
>> mechanism or not.
>
> As Peter said, there was no questions in this patch, so how were we to
> know that this was something that you all were asking?
>
> Also, you need to provide lots of information in the changelog itself
> about whatever "SBAT" is, as that is not anything that anyone should be
> forced to look up (links go dead over time.)
>

Very valid point, "SBAT" is certainly not something very standard. The
RFC should've contained the description and a clear question with a
question mark at the end.

>> We can, of course, iron out the details whether it
>> should be "linux.org"/"linux.com"/"lore.kernel.org/lkml/" or
>> "linux.onion" and where to put objcopy call, whether to silence its
>> output or not but these are rather implemntation details.
>
> It's a sign that this change was not thought out at all, as the
> follow-up questions, and lack of answers, showed in detail.

...

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

>> Following the discussion, it seems that at least x86 maintainer[s] are
>> opposed to the very idea of having SBAT revocation mechanism integrated
>> upstream because it's hard to meaningfully define what epoch is.
>
> You all did not even consider how this might work with our existing
> release process OR how we handle security fixes today.  In fact, you
> totally ignored it, and didn't even do some basic research into our past
> history to see how this new feature would actually work had it been
> present 10 years ago.
>
> You need to convince us "of course we would be foolish to not accept
> this patch because you properly researched it, documented it, and tied
> it all into our existing release and security and other policies and
> proceedures".  But none of that happened here, so we would be foolish to
> ACCEPT this patch, right?
>
> 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. 

>> This is
>> OK (which doesn't mean we all agree to that) but as there's real need to
>> revoke "bad" (in UEFI SecureBoot sense) kernels, distros will likely
>> come up with their custom, downstream only ways to do it. Without an
>> upstream reference, however, they may come up with very differently
>> looking SBAT sections, this may or may not be problematic in the future,
>> who knows.
>
> You all haven't even properly defined what "bad" means!  Or who would
> determine it!  Or how it would work with our decades-old release process
> that has evolved over time.  Or how it would tie into our existing
> security fixing policies and processes.
>
> In fact, it is a complete end-run around all of that, with only a "trust
> us, we will update the number when we want to" statement.  Also
> without even defining who "us" is.
>
> And if a security policy doesn't even define who is going to be
> determining the security policy at all, is it a security policy you want
> in Linux?

All these are very valid questions, of course, and in no way I'm trying
to say that they were answered in the RFC or in the following
discussion. The only thing I'm saying is that the upstream discussion
itself is valuable and should not be discouraged.

-- 
Vitaly