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 513E9AC1304 for ; Mon, 4 Dec 2023 12:59:08 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=ga8gZxsDLkNHgrHi2mXF1XzvRELFVShlpfiOVpINYXQ=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1701694747; v=1; b=URFDcNQkXKIz3/UyGnxnBL1pl2XFX9ydCwBjrgFK1+izCTlIthghyluEAsOlXlpX6OjdUme9 9s9VoOoT/ghb6UNyhWf6ekLcjHxoAZ7aGaKDZhi94oAVN0Vl1Tzv5acLGQ821RWEYFI5BvjYZ7D MTQOC1uUvsFb9gIfUNXoCvL8= X-Received: by 127.0.0.2 with SMTP id 2e05YY7687511xIMwZgTbB3z; Mon, 04 Dec 2023 04:59:07 -0800 X-Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web11.67902.1701694745921010547 for ; Mon, 04 Dec 2023 04:59:06 -0800 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 36C9FCE0F8E for ; Mon, 4 Dec 2023 12:59:03 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E4ACC433CA for ; Mon, 4 Dec 2023 12:59:00 +0000 (UTC) X-Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2ca0f21e48cso610421fa.2 for ; Mon, 04 Dec 2023 04:59:00 -0800 (PST) X-Gm-Message-State: vRvmSSwMZpIRJAZ7UaAUAvMlx7686176AA= X-Google-Smtp-Source: AGHT+IEbtGy3VMpuKm5ga/wqJr68x47tVuAsx15+F2V/VgNAqg4VB/sv7vAAjvUjQFJZhnC9glGmOZ5vGAn5lIggTLM= X-Received: by 2002:a2e:9614:0:b0:2c9:c212:2529 with SMTP id v20-20020a2e9614000000b002c9c2122529mr2962487ljh.28.1701694738545; Mon, 04 Dec 2023 04:58:58 -0800 (PST) MIME-Version: 1.0 References: <20231204095215.1053032-1-ardb@google.com> <0d62a08e-a153-447a-acb9-b937a74f35f3@amazon.com> In-Reply-To: From: "Ard Biesheuvel" Date: Mon, 4 Dec 2023 13:58:46 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled To: Alexander Graf Cc: Gerd Hoffmann , Ard Biesheuvel , devel@edk2.groups.io, =?UTF-8?B?TO+/vXN6bO+/vSDvv71yc2Vr?= , Oliver Steffen , "Herrenschmidt, Benjamin" , Lennart Poettering , Peter Jones , Matthew Garrett 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,ardb@kernel.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=URFDcNQk; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (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 On Mon, 4 Dec 2023 at 13:38, Alexander Graf wrote: > > > On 04.12.23 13:20, Gerd Hoffmann wrote: > > Hi, > > > >> (hint: You really don't want or need shim on ARM. The only reason for shim > >> is that on most x86 desktop systems, users will have the MS keys > >> preinstalled. The MS Secure Boot concept however is terribly broken: Any > >> compromise of any of the MS signed binaries jeopardizes your boot chain. > >> You're a lot better off installing *only* your distribution's key material. > >> 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. I think we're all better off as > community if we don't repeat the mistakes we did on x86 on ARM. > > 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. > > The same applies to RHEL-on-EC2, where you can bring your own db. > > > > 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 :). > > Once you sorted that bit out, we can start talking about paths to remove > shim on select x86 environments such as VMs. > > > > 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. Fight the battle please, we'll all be off with an easier boot > stack as a result :). This bug here alone already shows you why shim is > a bad idea conceptually. Necessary in an MS dominated world, but still bad. > > If there are concerns around tooling differences (like mokutil), let's > look at how we can unify/simplify the user experience instead. > I don't think it helps to go off on a tangent about why shim exists and why it is so terrible, as I don't think there is actually any disagreement about that. But now that we are, let me add my 2c as well :-) For the patch under discussion here, I think that Gerd's suggestion is to have both a PCD and a QEMU variable, and use the PCD unless the variable has a value. I'm on the fence here: I would like to accommodate users, but adding another control that the distros are just going to set and forget is just going to make the mess bigger. What is even worse: arm64 system firmware will have to deal with this as well, and disable the protocol in order to run distro installers. And once the tightened MS requirements for NX compat come into effect, they will have to add another workaround for this as well, and so we'll probably end up with generations of arm64 hardware with a 'enable memory attributes protocol' option in their BIOS menus. And guess what the default setting is likely to be? I am quite disappointed with the complete lack of involvement from the folks who develop and deploy shim, and instead, third parties (and users) are the ones chasing me and people like Gerd (who work on QEMU or EDK2 rather than shim) to clean up the mess. If the shim developers (or anyone else) can suggest some kind of heuristic for deciding whether a broken shim is calling into the protocol, I'd be more than happy to add more code to avoid the need for a QEMU command line option in the common case. But just turning it off via a PCD or otherwise is not something I am willing to entertain. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112040): https://edk2.groups.io/g/devel/message/112040 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] -=-=-=-=-=-=-=-=-=-=-=-