From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1240AEB64DC for ; Fri, 21 Jul 2023 13:34:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231262AbjGUNeF (ORCPT ); Fri, 21 Jul 2023 09:34:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229828AbjGUNeE (ORCPT ); Fri, 21 Jul 2023 09:34:04 -0400 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 544A9121; Fri, 21 Jul 2023 06:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1689946442; bh=TiphdHXvMuUcO0i6GCIlwWLbWEkBbJfN4Wq1cM4dYMA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=ZgX3Eqfm2MYvmUoX1/SrOMSPA4Jg5S+9AmCkRja0afIcgKm+X8kmPSqHtmlGIMopa 2Xi1xVod18cKjY3ETYRKZapGEKqNaQkygV7Jco212CpgdF4qaEyX2gbB2RWDW2ln1b QKMuuP+A6M/4OEtvEnnKkYLAWcbj3A9mEiycNG0g= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id DC7CB1285F6A; Fri, 21 Jul 2023 09:34:02 -0400 (EDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavis, port 10024) with ESMTP id FJi4xGw7Wxjc; Fri, 21 Jul 2023 09:34:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1689946442; bh=TiphdHXvMuUcO0i6GCIlwWLbWEkBbJfN4Wq1cM4dYMA=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=ZgX3Eqfm2MYvmUoX1/SrOMSPA4Jg5S+9AmCkRja0afIcgKm+X8kmPSqHtmlGIMopa 2Xi1xVod18cKjY3ETYRKZapGEKqNaQkygV7Jco212CpgdF4qaEyX2gbB2RWDW2ln1b QKMuuP+A6M/4OEtvEnnKkYLAWcbj3A9mEiycNG0g= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 0AA6B1285F0E; Fri, 21 Jul 2023 09:34:00 -0400 (EDT) Message-ID: Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage From: James Bottomley To: Luca Boccassi Cc: Eric Snowberg , Ard Biesheuvel , "Daniel P." =?ISO-8859-1?Q?Berrang=E9?= , Emanuele Giuseppe Esposito , "x86@kernel.org" , Thomas Gleixner , "lennart@poettering.net" , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Andrew Morton , Masahiro Yamada , Alexander Potapenko , Nick Desaulniers , Vitaly Kuznetsov , open list , "linux-efi@vger.kernel.org" , "keyrings@vger.kernel.org" , Jarkko Sakkinen Date: Fri, 21 Jul 2023 09:33:56 -0400 In-Reply-To: References: <20230711154449.1378385-1-eesposit@redhat.com> <0aa647f719103e8620d7209cbde40f04a7334749.camel@HansenPartnership.com> <635B383C-38A5-479E-80A6-358D5F90988B@oracle.com> <137ddc2957d43576afd37afb0bedab3ceea1f8d7.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Fri, 2023-07-21 at 14:10 +0100, Luca Boccassi wrote: > On Fri, 21 Jul 2023 at 14:01, James Bottomley > wrote: [...] > > Well, my job is to be concerned about how individuals who want to > > own their own keys, either in MoK or db, participate in this, so I > > am mostly thinking about local signing.  Whatever we decide, there > > must be a local workflow pathway. > > Sure but for local signing via MoK that's obviously fine, as one gets > to keep the pieces. AFAIK it's a different flow in Shim whether > something is authorized by MoK, DB or the built-in cert, so having > different policies built-in for those different cases should be > doable. Actually at the moment even if Shim loads the image, if it > gets authorized by DB .sbat isn't checked at all. So let's be sure we mean the same thing here. There is really no third party CA. Microsoft gives the distributions a signing key to allow them to sign their version of shim. Some distributions, like Red Hat, also embed their signing certificates in shim, so shim can distinguish between a RH key and another key added to MokList. However, some distributions, like SUSE, insist that all signing keys be approved by the machine owner (so no embedded shim certs for non-enterprise) and their shim can't distinguish between SUSE keys and machine owner additions. Given the variances in key handling, I think trying to distinguish between official and developer keys is a huge addition of complexity we don't need, so there has to be a workflow that functions for both and that workflow would seem to be allowing non-existent or empty sbat sections. Official key holders would *always* add sbat sections, so there's really no problem that needs a solution to be mandated here. James