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;
MIME-Version: 1.0
References: <20230711154449.1378385-1-eesposit@redhat.com> <ZK/9MlTh435FP5Ji@gambale.home>
 <df7941b9-11ea-9abd-e070-4e9926aecdc3@redhat.com> <CAMw=ZnTSyeL4x1o_GVKNsZdCUe2D2H53quK-TSFhOkuONjC73A@mail.gmail.com>
In-Reply-To: <CAMw=ZnTSyeL4x1o_GVKNsZdCUe2D2H53quK-TSFhOkuONjC73A@mail.gmail.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Date:   Tue, 18 Jul 2023 17:51:56 +0200
Message-ID: <CABgObfb_jGgs-yMSsHtHhEStFDp4f072LN7pW+3dSuVhAP87Ag@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     Luca Boccassi <bluca@debian.org>
Cc:     Ard Biesheuvel <ardb@kernel.org>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        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>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jul 18, 2023 at 4:03=E2=80=AFPM Luca Boccassi <bluca@debian.org> wr=
ote:
>> If you try to do this for the OS, however, Linux's "vulnerabilities are
>> just bugs" mantra hits hard---more specifically the reverse: all bugs
>> are potential vulnerabilities.  Sure you can hope for the best, which is
>> what we do with module signing and with the (non-upstream) secure boot
>> lockdown patches.  In the end, however, an unpatched code execution or
>> memory write vulnerability is always a potential rootkit.  While we
>> don't have _too_ many of those, there are enough that the idea of a
>> revocation index becomes completely unfeasible, not too mention those
>> that are fixed silently not because "that's the way Linus does it" but
>> rather because we genuinely didn't think of them as security fixes.
>
> Lockdown is upstream and has been for several years.

Almost (the missing part is automatically locking down the kernel if
running under secure boot, which is what I referred to).

> Grub also gets plenty of bug fixes that are not classed as security
> fixes, and so does Shim, and so does everything else. And they both
> have plenty of user interaction, and plenty of variability. Heck, Grub
> has its own complex configuration language that can take live input at
> boot, _and_ reimplements most of the kernel filesystems!
>
> But anyway, from the point of view of the 3rd party CA plus Shim
> workflow, they are the same, and can be treated the same - sorry, but
> the kernel is not special in any way. The only thing that matters is
> if, given a bug, somebody either observed it being used as a secure
> boot bypass by bad actors in the wild, or was bothered enough to write
> down a self-contained, real and fully working proof of concept for
> secure boot bypass.

Maybe I'm misunderstanding but this makes no sense to me. Any code
execution vulnerability by definition lets the attacker run unsigned
code in the kernel, which is a secure boot bypass. Linux is indeed not
special in this respect; "wait for someone to exploit it and then bump
the number" is at least dubious for Grub as well.

In my opinion there is still a difference though, in that the amount
of untrusted/unsigned userspace code that the kernel is exposed to,
absolutely dwarfs the amount of code and data that a bootloader is
exposed to. For the case of filesystems, for example, Linux is a lot
more optimized, it's multithreaded, it's read/write. Grub is a lot
simpler.

> > So perhaps there could be some kind of protocol that would let a new
> > kernel tell the bootloader "don't boot an older kernel than me in the
> > future".  It could even be an extension to the SBAT spec itself.  I
> > haven't really thought much about it, tbh.  However, I'm quite positive
> > that a revocation index attached to the kernel image cannot really work
> > as a concept, not even if it is managed by the distro.
>
> You are pretty much describing SBAT there. Except for the detail that
> it can't be the component that can be compromised that tells you
> whether it's compromised and you should trust it... A system's SBAT
> policy is a single entity, managed centrally, and deployed everywhere.

Fine, so can the SBAT spec be extended to have some kind of version
that is not a single number? If that is provided, Linux could have the
mechanism to place the kernel version in the .sbat section. But I
agree with Borislav, Greg and others that a single revocation index
simply doesn't cut it.

Paolo