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 0BA789419DA for ; Mon, 4 Dec 2023 14:52:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=ymu3YX3OxRlYybZiSGfWpZueblFpSRNLBfAbO5WKwaU=; 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=1701701577; v=1; b=NKZDwrZQhoAiHiC/TI2ao9Nk8jVblbq18oY+rHXZuNXG9Gh8GndM+b9Wbxl9Y0kuOeAX6ZCP y/wniSw1pU7/GHCGLRxkJels+iLcQhUNIT172DCjUMHVRgZZOSBrNjJmfVKBvkDjomoDTiqwXwe g5jfR8zN4z8+kNmcK7Da0RdI= X-Received: by 127.0.0.2 with SMTP id 7920YY7687511xgBOaVcQiNo; Mon, 04 Dec 2023 06:52:57 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web10.71281.1701701577063200958 for ; Mon, 04 Dec 2023 06:52:57 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-307-r6_XFGYZN8eEjX5RyaHA9Q-1; Mon, 04 Dec 2023 09:52:51 -0500 X-MC-Unique: r6_XFGYZN8eEjX5RyaHA9Q-1 X-Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (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 C77D2101A550; Mon, 4 Dec 2023 14:52:50 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.194.201]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6ACB7492BE0; Mon, 4 Dec 2023 14:52:50 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id B924D7613B; Mon, 4 Dec 2023 15:52:48 +0100 (CET) Date: Mon, 4 Dec 2023 15:52:48 +0100 From: "Gerd Hoffmann" To: Alexander Graf Cc: Ard Biesheuvel , devel@edk2.groups.io, Ard Biesheuvel , =?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.9 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: Rl2EWDeCbLgwGNQftYfdOF0Mx7686176AA= 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=NKZDwrZQ; 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, > > > That way you at least you know who you trust. Just remove shim. Have a look > > > at how Amazon Linux 2023 did it [2] :)) > > You are in the luxurious position to run your own distro on your own > > platform, which makes this totally easy. > Sure, we're cheating a bit on x86. But for ARM, the same story holds true > for RH as well. There are a solid number of ARM systems that implement UEFI > Secure Boot today - and none of them (that I'm aware of) provision a > Microsoft 3rd party key. Didn't got my hands on any such arm system. How do you enroll the keys on those systems? Do they offer the option to read the 'db' keys from files on distro boot media? Or do they expect the distro boot loader (or installer) to enroll keys and enable secure boot (which is supported by systemd-boot I think)? > In fact, for virtual machines you're in the exact same position as EC2: If > virt-install only provisions Red Hat Secure Boot keys by default when you > install Fedora or RHEL guests, you've already increased your guests' > security posture significantly. Well, no. One problem is install media, where you really have only one entry point (EFI/BOOT/BOOT${ARCH}.EFI) which must work under all circumstances. Which must be shim with microsoft signature (and ideally distro signature too) on x64. When booting cloud images and the platform allowing for 'bring-your-own-varstore', then yes, it is simpler and doable. > > The RH bootloader team considers shim.efi being an essential part of the > > boot chain (to the point that the distro grub.efi throws errors with > > secure boot being enabled and shim.efi missing), and on x86 bare metal > > it actually is essential because hardware usually ships with only the > > microsoft certificate enrolled. > See above, the key (in your case) is to not treat ARM and x86 identical. And > yes, the (downstream) shim patches for grub break normal grub secure boot > support. But that's a bug - not a feature :). 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. > > At least they promised to sign shim with both distro and microsoft keys > > on the next update, so I have the option to enroll the distro instead of > > the micosoft keys in 'db' on platforms where this is possible. > > Shim really has no place in a world where you have a distro key enrolled. Except for https://github.com/rhboot/shim/blob/main/SBAT.md > Fight the battle please, we'll all be off with an easier boot stack as a > result :). Trust me, I had my fair share of battles already, and I still have multiple open bug reports. > If there are concerns around tooling differences (like mokutil), let's look > at how we can unify/simplify the user experience instead. IMHO it essentially it comes down to standardize a few things. Most importantly placing the distro secure boot certificate on some well-known location on the install media, so tooling like virt-install can pre-load it into 'db' of the guest it is going to install. Something similar for cloud images, so OpenStack / EC2 / whatever can do the same. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112044): https://edk2.groups.io/g/devel/message/112044 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] -=-=-=-=-=-=-=-=-=-=-=-