From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 511537803E9 for ; Tue, 5 Dec 2023 09:36:55 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=tRHLgaQH/5WLPVWhD1QEptvkX3iBe0qmX7Co/fSiivc=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition; s=20140610; t=1701769014; v=1; b=Lx2ZO901tO1rhdqDtflqA8fFEjEUrEnFK0jI/8I2PGHjGemkZam9RkCoZXaFIbNLN6tUWoDP 8DNKA0EpDt7/xdlvUvXAT4xI9LIBrsGk4L/LlAJMd3H7y+NSRUpEZMKhTW8N7lCqNb+KQMR1BvU DPLf3L+Gq7/qBmvYrZYtmToc= X-Received: by 127.0.0.2 with SMTP id 8JI5YY7687511xpa50YIssJg; Tue, 05 Dec 2023 01:36:54 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.95907.1701769012803432079 for ; Tue, 05 Dec 2023 01:36:53 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-692-DuSOpXqRPye_-Ca7fuwTCg-1; Tue, 05 Dec 2023 04:36:49 -0500 X-MC-Unique: DuSOpXqRPye_-Ca7fuwTCg-1 X-Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8107629ABA12; Tue, 5 Dec 2023 09:36:48 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.194.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C033A2026D66; Tue, 5 Dec 2023 09:36:45 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id 09A9B7670B; Mon, 4 Dec 2023 23:24:29 +0100 (CET) Date: Mon, 4 Dec 2023 23:24:29 +0100 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: Alexander Graf , Ard Biesheuvel , devel@edk2.groups.io, =?utf-8?B?TO+/vXN6bO+/vSDvv71yc2Vr?= , Oliver Steffen , "Herrenschmidt, Benjamin" , Lennart Poettering , Peter Jones , Matthew Garrett Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled Message-ID: References: <20231204095215.1053032-1-ardb@google.com> <0d62a08e-a153-447a-acb9-b937a74f35f3@amazon.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 9nlcO99cthEwiWiXcA8IYCcPx7686176AA= Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Lx2ZO901; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Hi, > > I'm with you on that. Unfortunately the boot loader team is not. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2108083 > > > > tl;dr: You can't boot Fedora in secure boot mode without microsoft keys > > today. grub.efi refuses to work without shim.efi, and shim.efi exists > > only in a microsoft-signed version (which differed from rhel were a > > second, redhat-signed shim binary exists). > > > > Oh, and the above applies to x86 only. On arm fedora shim.efi is not > > signed and grub.efi is signed with the (public) redhat test keys. > > So what is holding Fedora back from providing a fixed shim binary if > it doesn't need to be signed by Microsoft? I'd love to have an serious answer for that question, but I havn't. Usually I get either no answer, or something along the lines of "-ENOTIME because of $otherwork". Right now waiting for v6.7-final before sending a new shim.efi to microsoft for signing and the desire to keep all archs in sync also plays a role (I guess). Technically there is no good reason, fedora even has a separate shim-unsigned-$arch.rpm which could be up-to-date all the time on all architectures, independent from the microsoft signing process. But that is right now at v15.6, which is not even the latest (v15.7) release. And 15.7 is more than one year old already ... > To be honest (and I know I am preaching to the choir here), the more i > learn about this, the less I am inclined to make *any* accommodations > whatsoever, given that the boot loader team obviously does not give a > shit about their crappy boot chain. Can understand that sentiment. Problem is this hits the wrong people, and the fallout goes beyond rhel + fedora because the rh team also maintains upstream shim. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112072): https://edk2.groups.io/g/devel/message/112072 Mute This Topic: https://groups.io/mt/102967690/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-