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]

Date:   Tue, 18 Jul 2023 17:51:56 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Luca Boccassi <bluca@...ian.org>
Cc:     Ard Biesheuvel <ardb@...nel.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>,
        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 Tue, Jul 18, 2023 at 4:03 PM Luca Boccassi <bluca@...ian.org> wrote:
>> 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