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: <2023071200-unopposed-unbuckled-cde8@gregkh> <CAMw=ZnTVRaqRmtz+sDj7AeAS7xivSu+56UgKbzmuW9+K6TTx1A@mail.gmail.com>
 <2023071239-progress-molasses-3b3d@gregkh> <CAMw=ZnRheXk7W_r-32bGymbHKdXc7aKUpwGAOX+k7DJkN+DiCQ@mail.gmail.com>
 <2023071229-dusk-repacking-da3a@gregkh> <CAMw=ZnSmZTBs+bJsQ_Y2CVO8K3OTuHOZDKW4cbxKpGbo4Vgs7Q@mail.gmail.com>
 <2023071226-crafty-deviator-12e2@gregkh> <CAMw=ZnRjnxWnmoFuw2prxFS55vAGQ1hpfKeHYFfG5Oa0LB_jYA@mail.gmail.com>
 <2023071233-empirical-overturn-744c@gregkh> <CAMw=ZnRRviBNi_LK9VOSUV9PNHe3jurUcLfgLpbTOsp_eE4WyA@mail.gmail.com>
 <2023071350-specked-botanist-6ba8@gregkh>
In-Reply-To: <2023071350-specked-botanist-6ba8@gregkh>
From:   Luca Boccassi <bluca@debian.org>
Date:   Fri, 14 Jul 2023 01:29:20 +0100
Message-ID: <CAMw=ZnQZ9ds3xsa2AZv_F13dB6rR4XzGPrBjJHSga1oU5xRezQ@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     Greg KH <gregkh@linuxfoundation.org>
Cc:     =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        Thomas Gleixner <tglx@linutronix.de>, lennart@poettering.net,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.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>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 13 Jul 2023 at 07:09, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jul 12, 2023 at 10:50:45PM +0100, Luca Boccassi wrote:
> > > Who is going to be responsible for determining that this number needs to
> > > be updated?
> >
> > Most likely those who understand the problem space - largely the group
> > of people maintaining the EFI stack, with various inputs, I imagine.
> > That's how it currently works for various bootloaders.
>
> We need specifics and to have people agree to do this, otherwise, again,
> this patch is useless.

Not really, as this is about mechanism, not process.

> > > How are they going to determine this?
> >
> > Again, very coarsely: does the current generation allow a secure boot
> > bypass -> revoked, else -> no change
>
> And how are you going to do that testing?  Who is going to do that?
> Does it happen today?

Of course it happens today, it even gets fancy names - black lotus,
boot hole, etc. If you want to know how it happens, read some papers,
join a security team, or a university research group, or some other
place that works in the specific field.

> > > What is their response time?
> > >
> > > Who will they be submitting the patch to this string in order to have it
> > > change?
> >
> > A bit too soon for exact details on processes given where we are, I think.
>
> Not at all, this is a proposal for a "security flag" for the kernel,
> getting this all decided now is the only correct way to determine if
> this is actually something that can work properly.

No, the question here was about mechanism and storage. And it already
works btw, it's just the kernel that's lagging behind, as usual.

> To just go "we are going to randomly add a number that will sometimes be
> incremented in the future to determine the buggyness of the kernel
> without saying who will control this, or how it will be done" is crazy.
>
> Would other operating systems or projects accept such a change without
> this information?
>
> Would you take this patch if you were responsible for kernel releases?

I think you are still missing one tiny bit of information: it is
already used in other projects

$ sudo objcopy -O binary --only-section=.sbat
/boot/efi/EFI/Debian/grubx64.efi /dev/stdout
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,3,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.debian,4,Debian,grub2,2.06-13,https://tracker.debian.org/pkg/grub2

> > > And how is any of this going to interact with stable kernel releases,
> > > long term kernel releases and end-of-life kernel releases?
> >
> > As above: does the current generation allow a secure boot bypass ->
> > revoked, else -> no change
>
> For all stable releases?

Doesn't matter how you call it, only if it's signed for the shim+3rd
party CA workflow

> > > How long will this feature have to be maintained?
> >
> > Until something else supplants EFI, I'd imagine
>
> So 40+ years, great, who is going to fund that?

Who funds EFI work?

> > > > The only thing that matters is, "if we had infinite space in DBX and
> > > > sensible ways to service it and nvram didn't wear down, would we
> > > > blocklist this component version" - if the answer is no, then nothing
> > > > happens. If the answer is yes, then the counter goes up.
> > >
> > > I suggest you all take a look at the past 10 years of kernel releases
> > > and changes (to pick a simple number) and determine what the number
> > > would be now if you were to start counting then.  Is it 10?  100?
> > > 10000?  What do you think it will be in the next 40 years?
> >
> > What do you think that would look like if it was all individual hashes
> > blocklisted in DBX instead? Because this is what we are talking about.
> > And, for the nth time, this is not about identifying individual bugs.
> > You do what, 3 releases a year? So 10 years time 3,
>
> I do a release or two a week across multiple stable kernel versions.
> For you to not notice that means that either the process is working
> really well, or that this type of function does not match how we do
> development and releases at all.

Or, third option, that's irrelevant for the case at hand.

> > then assuming
> > every single release you have made is completely and hopelessly broken
> > in different ways, but each is only discovered one at a time exactly
> > once per release, then the generation counter would be 30. That's your
> > absolutely worst case scenario. Now try to think about how hash
> > entries we'd need in DBX for the exact same worst case scenario, and
> > the reason SBAT has been implemented should become very obvious, very
> > quickly.
>
> I'm not saying "individual hashes" anymore, sure, I'll give you your one
> number, but even then, I don't see how it makes any sense at all in our
> current ecosystem of releases.
>
> So I need to see this documented very very well to even be able to
> consider it.

Well then, it's your lucky day! As it is documented, with examples and all:

https://github.com/rhboot/shim/blob/main/SBAT.example.md

the kernel is just one of many consumers of this protocol, so
obviously the documentation for it lives with the protocol owner,
which is Shim.

> > > We have a plethora of kernel changes in our history to learn from here,
> > > please do so and show how this will affect us going forward based on our
> > > past, otherwise we have no way of knowing how any of this is going to
> > > work.
> >
> > I am not aware of anything similar enough, but please do point those
> > out if you are.
>
> Audit our past history and document when the number would have changed
> please.

Sure, where do I send the invoice?