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>
 <ZLABozIRVGmwuIBf@gambale.home> <CAMw=ZnSF_s-+74gURPpXCU+YSTeXDAYfVp_A9DOFoW7oL2T_Hw@mail.gmail.com>
 <CAMj1kXG1Sk1G=3PCRmiHZ24qPdUYiGRkSbq57u1-KUbyorX8Lg@mail.gmail.com>
In-Reply-To: <CAMj1kXG1Sk1G=3PCRmiHZ24qPdUYiGRkSbq57u1-KUbyorX8Lg@mail.gmail.com>
From:   Luca Boccassi <bluca@debian.org>
Date:   Fri, 14 Jul 2023 10:25:45 +0100
Message-ID: <CAMw=ZnRtLSQ38csrOU1aSjq2JoE4up5i5KciONJcS_T8ggB3LA@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     Peter Jones <pjones@redhat.com>,
        Matthew Garrett <mjg59@srcf.ucam.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, linux-efi@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 14 Jul 2023 at 09:52, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> (cc Peter and Matthew)
>
> On Fri, 14 Jul 2023 at 00:32, Luca Boccassi <bluca@debian.org> wrote:
> >
> > On Thu, 13 Jul 2023 at 14:52, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > >
> > > Note that by Windows-crippled, I mean x86 PCs built by OEMs who care
> > > about nothing other than the Windows logo sticker. These PCs often don't
> > > allow secure boot keys to be modified by the owner of the machine, or
> > > secure boot to be disabled at all. This is why shim exists, not because
> > > UEFI secure boot is broken by design.
> >
> > AFAIK that's not only against the spec but also the logo
> > certification, which x86 OEMs are doing that and in which models?
> > Happy to flag that and inquire.
>
> Thanks. My Yoga C630 Snapdragon laptop definitely does not allow me to
> update the keys from the UI, but it does allow me to disable secure
> boot. It might work with SetVariable() directly but I've never tried.

That's not an x86 machine though? For Arm IIRC the logo certification
requirement was more lax there (or more locked down, depending on your
point of view), at least in the past. I am not sure what is the
current state.