Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Julian Andres Klode Newsgroups: linux.debian.kernel Subject: Re: How to revoke Debian kernels for secure boot Date: Thu, 14 Dec 2023 10:00:02 +0100 Message-ID: References: X-Original-To: debian-kernel@lists.debian.org, debian-efi@lists.debian.org X-Mailbox-Line: From debian-kernel-request@lists.debian.org Thu Dec 14 08:51:09 2023 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.511 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate:hard: -5.5 X-Gm-Message-State: AOJu0YwIQ4tNux3nj/MvlSbWBFSWQ/pHZP7WlzoosRBQPuPwNXbRcZJ5 WDMVVHFjeXm0qHL4dpWD7g2LCbMfbF8= X-Google-SMTP-Source: AGHT+IFoTNk3TCsM5z5FliT5Cl9B3GrTEtkfin4K7euXsgzWOctLyGhJyrFG2qa2bBFh3E9pxf3i4Q== X-Received: by 2002:a17:906:20c3:b0:a1c:91eb:63cf with SMTP id c3-20020a17090620c300b00a1c91eb63cfmr9146450ejc.14.1702543846900; Thu, 14 Dec 2023 00:50:46 -0800 (PST) Sender: robomod@news.nic.it Mail-Followup-To: Julian Andres Klode , debian-kernel@lists.debian.org, debian-efi@lists.debian.org Accept-Language: de-DE, de, en-GB, en-US, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: archive/latest/141029 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20231214094741.GA4157425@debian.org Approved: robomod@news.nic.it Lines: 34 Organization: linux.* mail to news gateway X-Original-Date: Thu, 14 Dec 2023 09:50:44 +0100 X-Original-Message-ID: <20231214094741.GA4157425@debian.org> X-Original-References: <20231213214727.hpqunnpouesan43e@shell.thinkmo.de> X-Original-Sender: Julian Andres Klode Xref: csiph.com linux.debian.kernel:81210 On Wed, Dec 13, 2023 at 10:18:40PM +0000, Dimitri John Ledkov wrote: > At the moment the best options are: > > - rotate online signing key > - build new shim with old signing key in vendorx (revoked ESL) > - build new kernels with old signing key built-in revoked keyring > > This is to ensure that old shim & old kernel can boot or kexec new kernels. > To ensure new shim cannot boot old kernels. > To ensure that new kernels cannot kexec old kernels. > > This is revocation strategy used by Canonical Kernel Team for Ubuntu > Kernels. > > There is no sbat for kernels yet (and/or nobody has yet started to use sbat > for kernels). Reading this summary also made me realize that if we do SBAT for kernels and want to rely it, we also need to make kernels *check* SBAT so that it is respected at kexec. This can be done two ways: - You do an SBAT self-check at startup to see if you are revoked yourself, which is what shim does - You check the SBAT of the kernel you are about to kexec I'd generally prefer the self-check I think because that also applies if you boot kernels via UEFI directly or something. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en