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 EA55DEB64DA for ; Thu, 20 Jul 2023 17:07:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230062AbjGTRHu (ORCPT ); Thu, 20 Jul 2023 13:07:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbjGTRHt (ORCPT ); Thu, 20 Jul 2023 13:07:49 -0400 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 848A7193; Thu, 20 Jul 2023 10:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1689872857; bh=glW40uY0uFwX/9MnPDdB2OI8tCiPfxvzTv6gvs9+Orw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=EQOWoZCSu3UjMQztHHrpJIOz6h+TL40/8jSm2Qr16lk9s4/ZN6Na7mNG/CbFE5g69 8tWicaM2WKEJSA9yHQOwf3xQ5IxTP3DDZTcta9XB6CRbsdaX/NH24B3vSt2uGnShP5 FI3Hmxt9L1Kx7yhKhRqYIER1pD+68CuuWMXomPBY= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id E4B69128648C; Thu, 20 Jul 2023 13:07:37 -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 ECnMdAaPFcSl; Thu, 20 Jul 2023 13:07:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1689872857; bh=glW40uY0uFwX/9MnPDdB2OI8tCiPfxvzTv6gvs9+Orw=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=EQOWoZCSu3UjMQztHHrpJIOz6h+TL40/8jSm2Qr16lk9s4/ZN6Na7mNG/CbFE5g69 8tWicaM2WKEJSA9yHQOwf3xQ5IxTP3DDZTcta9XB6CRbsdaX/NH24B3vSt2uGnShP5 FI3Hmxt9L1Kx7yhKhRqYIER1pD+68CuuWMXomPBY= 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) server-digest SHA256) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 0410A1286255; Thu, 20 Jul 2023 13:07:35 -0400 (EDT) Message-ID: Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage From: James Bottomley To: Eric Snowberg , Ard Biesheuvel Cc: "Daniel P." =?ISO-8859-1?Q?Berrang=E9?= , Emanuele Giuseppe Esposito , "x86@kernel.org" , Thomas Gleixner , "bluca@debian.org" , "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: Thu, 20 Jul 2023 13:07:34 -0400 In-Reply-To: References: <20230711154449.1378385-1-eesposit@redhat.com> <0aa647f719103e8620d7209cbde40f04a7334749.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 Thu, 2023-07-20 at 16:46 +0000, Eric Snowberg wrote: > If a distro adds a SBAT section to either their UKI, or if kernel > SBAT enforcement is turned on from GRUB2 by default, there is one > piece missing that would need to be handled by the mainline kernel > which is SBAT enforcement for kexec. This would mean the revocations > SBAT protect against would need to be referenced before doing the > signature validation in kexec. If this is not added, any distro that > allows kexec really doesn’t have a SBAT protected kernel. Um, actually, this is actually one of the misunderstandings of the whole thread: sbat is a revocation mechanism for protecting EFI boot security. It's design is to prevent malicious actors exploiting buggy code to get into the EFI boot system before ExitBootServices is called and nothing more. The kernel's intrusion into EFI boot security is tiny: it's basically the EFI stub up to ExitBootServices, so even if the kernel were to have an sbat number it would obviously be under the control of the maintainers of only that code (i.e. Ard) and it would only rev if we actually found a usable exploit in the efi stub. As far as kexec is concerned, ExitBootServices is long gone and nothing a future kexec'd kernel can do can alter that, so there's no EFI security benefit to making kexec sbat aware, and thus it seems there's no need to do anything about it for kexec. Now if we're interested in sbat as a more general revocation mechanism, that might change, but I think sbat is too tightly designed for the problems of EFI variables to be more generally useful. James