From mboxrd@z Thu Jan 1 00:00:00 1970 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.1511.1687277173490615601 for ; Tue, 20 Jun 2023 09:06:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Z2AYKVaq; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687277172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RYFiLDfMOzR78oK4AT4qXNt7y1mUVP7fEj+6e69B5NA=; b=Z2AYKVaqP1p+6siseDsOaGSxsFs24XvqLCBlL99RWx67Hyjnj/f0ibQXsYFOFt4ytvdjLk Jh+51BRBwvB05cl1i1qk3m7xXjNO2CTJI1tkknkRDtd2Tmdw5vYaTp3Onux47lJ7TN0W/h jNTE9OWBPudUInNSb8dipx6WlIofuTQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-494-H--qF3oUOtCS8Ub1AX3zgA-1; Tue, 20 Jun 2023 12:05:55 -0400 X-MC-Unique: H--qF3oUOtCS8Ub1AX3zgA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3211C3810B37; Tue, 20 Jun 2023 16:03:23 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2CF3F15230A0; Tue, 20 Jun 2023 16:03:22 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id AD16C1803082; Tue, 20 Jun 2023 18:03:20 +0200 (CEST) Date: Tue, 20 Jun 2023 18:03:20 +0200 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: Oliver Steffen , edk2-devel-groups-io , Ard Biesheuvel , Daniel Schaefer , Eric Dong , Leif Lindholm , Liming Gao , Michael D Kinney , Rahul Kumar , Ray Ni , Sami Mujawar , Sunil V L , Zhiguang Liu , Taylor Beebe , Oliver Smith-Denny , Michael Kubacki Subject: Re: [PATCH 1/1] ArmPkg: Add Pcd to disable EFI_MEMORY_ATTRIBUTE_PROTOCOL Message-ID: References: <20230619203244.228933-1-osteffen@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 20, 2023 at 04:16:40PM +0300, Ard Biesheuvel wrote: > On Tue, Jun 20, 2023, 12:33 Gerd Hoffmann wrote: > > > On Mon, Jun 19, 2023 at 10:32:25PM +0200, Oliver Steffen wrote: > > > Recent versions of shim (15.6 and 15.7) crash when the newly added > > > EFI_MEMORY_ATTRIBUTE_PROTOCOL is provided by the firmware. To allow > > > existing installations to boot, provide a workaround in form of a Pcd > > > that allows tuning it off at build time (defaults to 'enabled'). > > > > Background: We have untested + broken code for > > EFI_MEMORY_ATTRIBUTE_PROTOCOL support in the listed shim releases. > > > > Now that firmware starts to actually provide that protocol the > > time bomb explodes. > > Fantastic. > > This is kind of a big deal, really, and just turning it off for ArmVirtQemu > does not help at all with the fact that these shim builds will crash on any > platform that implements the protocol. (Including x86) Sure. This hits VM firmware first because we quickly rebase our builds to new edk2 stable tags. But yes, this is not limited to VMs and likewise not limited to arm. > Given that secure boot is kind of pointless on this particular platform > anyway, maybe this is a good opportunity to make shim optional in the boot > chain? I understand that this does not fix existing builds but shim proves > to be such a problematic component that you really should not be using it > if there is no need. I'd love to ditch shim.efi, even with secure boot. For VMs one can just enroll the distro signing certificate to 'db' and be done with it. Unfortunately shim has a solid position being *the* entry point for linux efi systems due to being the only piece of software carrying a microsoft signature. Especially on install media you can't really have more than one (such as different binaries depending on whenever secure boot is on or off). For installed systems and cloud images shim also creates/restores BootNNNN entries. Additional problem is that shim is the piece of software which handles sbat revocations, so even in case the distro cert is enrolled in 'db' so the certificate handling implemented by shim is not needed I can't just ignore shim.efi. > As for the protocol, this has its own set of problems, and the bug in > question can partly be blamed on the misdesigned api, which has separate > set and clear methods. Not only does this force the implementation to > traverse the page tables twice for the common case of switching between RO > and XP or vice versa, it also means we lose any transactional properties of > a RO <-> XP switch. I.e., if we could make it the implementation's > responsibility to ensure that such a transformation either completes > successfully, or otherwise, doesn't make any modifications at all, the risk > of ending up in a limbo state is reduced significantly. > > So maybe there is still opportunity for specifying a MemoryAttributes2 > protocol with a single method for set and clear? We could just drop the > current one in that case. Sounds reasonable to me. > In any case, while i can see how this patch helps make all your ci status > icons turn green again, it does so by papering over the underlying issue so > I'm not a fan. Yes. It's not a solution, it's a workaround which we could use to turn off EFI_MEMORY_ATTRIBUTE_PROTOCOL for a year or two, depending on how quickly the shim / distro folks get their act together and updates rolled out. I'm not a fan either, but we need some temporary stopgap, and given that others likely meet the very same problem too we figured sending it to the list is a good idea, and here we are ;) take care, Gerd