Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Jul 2023 11:16:37 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Vitaly Kuznetsov <vkuznets@redhat.com>
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        bluca@debian.org, lennart@poettering.net,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Alexander Potapenko <glider@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Daniel P =?iso-8859-1?Q?=2E_Berrang=E9?= <berrange@redhat.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
Message-ID: <20230713091637.GE3138667@hirez.programming.kicks-ass.net>
References: <20230711154449.1378385-1-eesposit@redhat.com>
 <2023071237-private-overhang-7f86@gregkh>
 <875y6o429i.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <875y6o429i.fsf@redhat.com>
Precedence: bulk

On Thu, Jul 13, 2023 at 10:57:45AM +0200, Vitaly Kuznetsov wrote:

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

If only it would have actually had that question in :/ But then we
would've still had the whole WTF is a SBAT(SHIT) and why should we care
discussion.

Fundamentally, I don't think upstream can care; upstream doesn't have a
signing key, it will never be revoked, bumping the upstream number
doesn't make sense -- ever.

> 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

Seriously ?!? kernel.org is the only sane option here, none of the
others make any damn sense.

> output or not but these are rather implemntation details. 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.

But there wasn't no question, was there. There isn't a single '?' in
that thing. And it starts of with random implementation detail blabber.

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

Well, if the various stake-holders can't even agree on things, things
are very bleak indeed.

I just don't see why upstream would want/need to carry any of this
because it has no meaning to us, we don't play in the secure boot pen,
not haz key etc.. (for good reasons IIUC).