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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230713091637.GE3138667@hirez.programming.kicks-ass.net>
Date:   Thu, 13 Jul 2023 11:16:37 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        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

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