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: <ZLEckECoBwzxLPAD@redhat.com>
Date:   Fri, 14 Jul 2023 10:59:44 +0100
From:   Daniel P. Berrangé <berrange@...hat.com>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Luca Boccassi <bluca@...ian.org>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        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>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Fri, Jul 14, 2023 at 11:33:44AM +0200, Ard Biesheuvel wrote:
> On Fri, 14 Jul 2023 at 01:13, Luca Boccassi <bluca@...ian.org> wrote:
> >
> > On Thu, 13 Jul 2023 at 14:33, Ard Biesheuvel <ardb@...nel.org> wrote:
> > > Therefore, I don't think it makes sense for the upstream kernel source
> > > to carry a revocation index. It is ultimately up to the owner of the
> > > signing key to decide which value gets signed along with the image, and
> > > this is fundamentally part of the configure/build/release workflow.  No
> > > distro builds and signs the upstream sources unmodified, so each signed
> > > release is a fork anyway, making a upstream revocation index almost
> > > meaningless. Also, while backporting revocation index bumps to -stable
> > > should not result in any issues, I don't think the associated
> > > bookkeeping belongs in the hands of the stable tree maintainers.
> >
> > The reason it's a good idea to store it here is because otherwise
> > there would need to be another external "registry" that matches 1:1,
> > and that is maintained identical everywhere, perfectly in sync,
> > forever, and any 'new' distro and/or distro maintainer would have to
> > discover and use that registry, and would be completely oblivious to
> > it otherwise.
> >
> 
> But why does there need to be a single, shared upstream 'generation
> id' in the first place? The upstream is just a bunch of source files
> that can be built in a million different ways, including for different
> architectures that can all boot via EFI.

To be clear, having an upstream SBAT component & generation id is
not a hard requirement.

It was/is just a best practice, based on the general OSS principal that
if every downstream consumer ends up mostly duplicating each others'
work, then it is usually a better idea to collaborate in the upstream
context and thus do it only once.

This is likely to be less error prone, because while some downstreams
may be informed enough to keep track of everythying an do updates at
the right time, others may not be.

That does put some of the burden onto the upstream maintainer instead,
but that may be tempered by the downstream maintainers responding to a
security issue doing the triage & submitting the needed change (if any)
back to upstream.

If the ultimate outcome of the discussion is that the kernel rejects
the idea of maintaining this info upstream, then downstreams will just
have to do the work individually & try to collaborate in other contexts
to get consistency in their approach. I think that'd be disappointing,
but it wouldn't be show-stopper.

The generation ID is intentionally coarse/crude, because its hard the
requirement of minimizing NVRAM storage over time. So it doesn't try
to distinguish amongst scenarios where some compilation configurations
are vulnerable and some are not. If one scenario needs revoking then
every scenario gets revoked. That's an unfortunate tradeoff, but one
that was / is not easy to avoid given the EFI NVRAM limitations.

It could be possible to have a distinct SBAT component ID per kernel
architecture, if it is anticipated that SecureBoot related flaws might
commonly only affect 1 arch, not all. Separate SBAT component per
arch shouldn't negatively impact NVRAM usage, as any deployment only
needs to deal with its own native arch.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|