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 364AFAC1070 for ; Tue, 5 Dec 2023 12:56:22 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=8I3y62AuN26Qfqd+BjRtjk3R5LZqYBh7n0FkhkaGWCw=; 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=1701780980; v=1; b=KqYHq7PlHxJ1uygu2DDYmJv46g7eZe04p0OZT8LwQMEk+e/CmGDXDSjTch4AEQsFm9PbqnCY QqWc/Lym9+SpDy8OBkdu8TMO/wbvQGbY+dOzWsr9k0Lp8nyPRNRwaJiySSSfYYpL2vDgfmh3/m+ vqfj52J9AaguJaziyD+wVQnE= X-Received: by 127.0.0.2 with SMTP id XWCIYY7687511x15NMr9bX7u; Tue, 05 Dec 2023 04:56:20 -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.web10.99640.1701780980000306014 for ; Tue, 05 Dec 2023 04:56:20 -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-60-LJL64PwgOEWbV7tZT1sgnQ-1; Tue, 05 Dec 2023 07:56:16 -0500 X-MC-Unique: LJL64PwgOEWbV7tZT1sgnQ-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 7739884A292; Tue, 5 Dec 2023 12:56:15 +0000 (UTC) X-Received: from dobby.home.kraxel.org (unknown [10.39.194.39]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 32CE340C6EB9; Tue, 5 Dec 2023 12:56:15 +0000 (UTC) X-Received: by dobby.home.kraxel.org (Postfix, from userid 1000) id 26C9377E74; Tue, 5 Dec 2023 13:56:10 +0100 (CET) Date: Tue, 5 Dec 2023 13:56:10 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io, graf@amazon.com Cc: Ard Biesheuvel , 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: <2akarcryet5nrxwby4bmo4s75j7dizwf2jzbkkv6ph4mjqmpef@ua2vzwukjf2f> References: <20231204095215.1053032-1-ardb@google.com> <0d62a08e-a153-447a-acb9-b937a74f35f3@amazon.com> <177dccf0-b214-4921-bcc7-29e672f04662@amazon.com> MIME-Version: 1.0 In-Reply-To: <177dccf0-b214-4921-bcc7-29e672f04662@amazon.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 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: RRBNbffOgisz2drZrf0LYROCx7686176AA= 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=KqYHq7Pl; 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 know of 3 categories: > > 1) U-Boot > 2) EC2 > 3) Windows ARM notebooks Thanks. > > 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. > > What if that shim immediately on start tries to see if it can load and > execute another binary at the same path instead? One more possible code path. I have my doubts that (a) the shim maintainers like the idea, and (b) that it actually improves the overall situation. Also note that it isn't a fixed binary. While grub.efi is the default you can pass something else on the command line, for example fwupd.efi or an UKI (unified kernel image). Also depending on circumstances shim decides to load fallback,efi or mokmanager.efi instead of grub.efi. So it's more complex that "try load grub.efi using standard efi protocols and if that works I'm done". > > Except for https://github.com/rhboot/shim/blob/main/SBAT.md > > I'm not quite sure what you're getting at :). > > First, the fundamental problem with huge dbx files is *precisely* because > the MS key is used in too many places. Smaller set of key scope means > smaller dbx. > > Second, I think the basic concept of introducing a new abstracted "version" > that dbx can match against is great. It would make dbx updates a lot more > efficient. So why don't we include that concept in the UEFI spec? Not sure what the status of this is, whenever it is just some kind of agreement between shim maintainers and microsoft, trying to keep dbx grow under control, or whenever there are any plans to add that to the uefi specs. Peter? Adding that to the uefi specs (and subsequently implement it in edk2) has the advantage that it wouldn't depend on shim.efi, and have the drawback that it'll take ages to have an effect due to the firmware update support for a big chunks of physical hardware being shitty (not that shim updates look that much better right now ...) My impression is that microsoft tries to improve the firmware security situation without depending on firmware updates if possible. Being more strict on the PE binaries they are willing to sign for secure boot is one step which goes into that category. > > 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. > > I don't know if putting it on a standardized location is really necessary. > If you boot with SB disabled and just as part of the installation process > install the distro keys, everything should fall into place nicely, no? Yes. Defining the key enrollment being job of the installer would work, at least for the cases where an installation actually happens. > For OpenStack/EC2/whatever, you don't run the installer, so you don't need a > standardized location for it. For EC2 the target image is completely opaque. > We don't even have (or want to have) a storage or file system driver to > access it. That's why it's in metadata (UefiData), separate from the disk > image. There is no standard for metadata though, along the lines of "when using this disk image with secure boot you should use that uefi varstore". What we have today is ec2-specific, you have to take care when creating the AMI. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112080): https://edk2.groups.io/g/devel/message/112080 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] -=-=-=-=-=-=-=-=-=-=-=-