Received: by 2002:a05:6358:7058:b0:131:369:b2a3 with SMTP id 24csp54612rwp; Wed, 12 Jul 2023 09:34:10 -0700 (PDT) X-Google-Smtp-Source: APBJJlFvD9Wo63pMAZUNnRbbQhY1LwiaVWXjVB693fnnSHTuGtRWRRcDw0NkqrpNm4S1/tlep1xd X-Received: by 2002:a17:906:dc:b0:988:f307:aea3 with SMTP id 28-20020a17090600dc00b00988f307aea3mr19850788eji.9.1689179649760; Wed, 12 Jul 2023 09:34:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689179649; cv=none; d=google.com; s=arc-20160816; b=VvvAOXaepFT0X5kZ/2w55abDSaooxq+R2Afd//2PsDOTzGIhBFBD/WmKZqhXtJ268N R2MBLKJvfyOAOW78fWeOhRp9jt+IC2f/ZV0pdK0kxRELhIajXXPyKpBBe8fr8erJEkmG gJ4pyezq3PGf5FKG2uU8CWmf+qRcoDlVWqAR0fNfP+FH3M2unhPWQU2Nt+MriApI7xed 23FmcwF9pRwWzqUJJjpvtFyKmvrFEVTXJEAjw1fnBrYYLnoBotjh21nq0gnjXYrH8Sf8 jYx4TLkVYj9y/RtCK51r3cOrDr4lFwx2SGQR/nlB6gc7OV2qFV2b7isxzCu4/b+6Wn9E DCXg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=xQX+yFKsIqdT3GZ6MtTD/T9YMN86/Bpx55GtGoHDun4=; fh=PPGZ50IArhvNtPjr9r1lt4T2IZC7LZL8X9VYQ59/zyE=; b=HoKAxba6bdSQ4yDRnImzGFLIKdNzQIrrgVaEMBBnBoAp1VuIJXDe7l7m64tKOA+4eb YaBAhqOaoJsdNafT3qFLWCp1G87DtqjYqAJeTun1+29lpLT/R3xahqRWGxvKhHWy8KGd +YvFYJPguiipNYoi83XE/AlP1Vt1wsTBkaZ83j4MF3IEjLxpn4ZuCzVkD/iMKorWrXMg rMCRxJJbfah234OyJ/MqNDiHAMT3qmerFJ3lS1IbN0yvxfJXaMAStm8kS6GDgYdJM8bJ foNnz450q35nVk2UlqVRkoEQSLXRFEGytFoPoKMkknZW5txNN+1011pND5tU79u/H58E Nxkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=gVbiiLS7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l15-20020a1709060e0f00b00992dc9d3b33si5392500eji.863.2023.07.12.09.33.44; Wed, 12 Jul 2023 09:34:09 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=gVbiiLS7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233793AbjGLPqE (ORCPT + 99 others); Wed, 12 Jul 2023 11:46:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231856AbjGLPqD (ORCPT ); Wed, 12 Jul 2023 11:46:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 700FE1BB for ; Wed, 12 Jul 2023 08:46:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7342F61873 for ; Wed, 12 Jul 2023 15:46:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57921C433C7; Wed, 12 Jul 2023 15:46:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1689176760; bh=VHFJLLY2tiHdpg6U8Yj5DS99OIzdiNoLkdg0LzRTC1c=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gVbiiLS7NqLNMDhlGkJaRSDdflmfKiip72CeUlV0kp3SRvPXvJ9BYNcPy3ztfxhb8 f+VqkHJ6h3Wf2vJZ34r5yG0j6vgIDyC5fuNm9KaimiH5qMOW5KdIJ84LfrkrCepjg9 9aDVNw+PSH5pjuuDtaSgbJPeDIvo7O86B+kwxzmQ= Date: Wed, 12 Jul 2023 17:45:58 +0200 From: Greg KH To: Emanuele Giuseppe Esposito Cc: 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 , Daniel P =?iso-8859-1?Q?=2E_Berrang=E9?= , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage Message-ID: <2023071237-private-overhang-7f86@gregkh> References: <20230711154449.1378385-1-eesposit@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230711154449.1378385-1-eesposit@redhat.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 11, 2023 at 11:44:49AM -0400, Emanuele Giuseppe Esposito wrote: > *Important*: this is just an RFC, as I am not expert in this area and > I don't know what's the best way to achieve this. > > v2: > * add standard "sbat,1,SBAT Version,..." header string > > The aim of this patch is to add a .sbat section to the linux binary > (https://github.com/rhboot/shim/blob/main/SBAT.md). > We mainly need SBAT in UKIs (Unified Kernel Images), as we might want > to revoke authorizations to specific signed PEs that were initially > considered as trusted. The reason might be for example a security issue > related to a specific linux release. > > A .sbat is simply a section containing a string with the component name > and a version number. This version number is compared with the value in > OVMF_VARS, and if it's less than the variable, the binary is not trusted, > even if it is correctly signed. > > Right now an UKI is built with a .sbat section containing the > systemd-stub sbat string (upstream + vendor), we would like to add > also a per-component specific string (ie vmlinux has its own sbat, > again upstream + vendor, each signed add-on its own and so on). > In this way, if a specific kernel version has an issue, we can revoke > it without compromising all other UKIs that are using a different > kernel with the same stub/initrd/something else. > > Issues with this patch: > * the string is added in a file but it is never deleted > * if the code is not modified but make is issued again, objcopy will > be called again and will fail because .sbat exists already, making > compilation fail > * minor display issue: objcopy command is printed in the make logs > > Signed-off-by: Emanuele Giuseppe Esposito > --- > arch/x86/boot/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile > index 9e38ffaadb5d..6982a50ba0c0 100644 > --- a/arch/x86/boot/Makefile > +++ b/arch/x86/boot/Makefile > @@ -83,6 +83,9 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \ > > $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE > $(call if_changed,image) > + @$(kecho) "sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md" > linux.sbat > + @$(kecho) "linux,1,The Linux Developers,linux,$(KERNELVERSION),https://linux.org" >> linux.sbat; Who controls "linux.org"? Why are you thinking they have anything to do with kernel development? This shows a huge lack of understanding of loads of things, please go get other experienced Red Hat developers to sign off on the next version of your patch before you ask the community to review it. As is, this is not going to go far. thanks, greg k-h