From: "Marcin Juszkiewicz" <marcin.juszkiewicz@linaro.org>
To: devel@edk2.groups.io, ardb@kernel.org, Alexander Graf <graf@amazon.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
Ard Biesheuvel <ardb@google.com>,
Oliver Steffen <osteffen@redhat.com>,
"Herrenschmidt, Benjamin" <benh@amazon.com>,
Lennart Poettering <mzxreary@0pointer.de>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Laszlo Ersek <lersek@redhat.com>
Subject: Re: [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled
Date: Tue, 5 Dec 2023 10:56:17 +0100 [thread overview]
Message-ID: <3edb6e4f-941e-4a69-a42f-304f3c1aafa6@linaro.org> (raw)
In-Reply-To: <CAMj1kXFYygZAoQVCY0Bww0K9fYHwTY9QWWBMxxEmQgVjWiXH+A@mail.gmail.com>
W dniu 4.12.2023 o 13:58, Ard Biesheuvel pisze:
> On Mon, 4 Dec 2023 at 13:38, Alexander Graf <graf@amazon.com> wrote:
>> On 04.12.23 13:20, Gerd Hoffmann wrote:
> 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.
I use 'sbsa-ref' with QEMU and upstream EDK2. And cannot use either RHEL
9.3 nor CentOS Stream 9 installers because they hang.
And this is not the only platform where upstream EDK2 is used.
Sure, I can hack something, use Grub from Debian or Fedora and get
things working but that's not solution.
Adding flags in 'Broken OS support' section of EDK2 settings feels like
bad idea. Especially when EFI app generating issues is developed by
company known for FOSS work.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112073): https://edk2.groups.io/g/devel/message/112073
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]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-12-05 9:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 9:52 [edk2-devel] [PATCH] ArmVirtPkg: Allow EFI memory attributes protocol to be disabled Ard Biesheuvel
2023-12-04 9:59 ` Ard Biesheuvel
2023-12-04 10:45 ` Alexander Graf via groups.io
2023-12-04 10:55 ` Ard Biesheuvel
2023-12-04 12:20 ` Gerd Hoffmann
2023-12-04 12:38 ` Alexander Graf via groups.io
2023-12-04 12:58 ` Ard Biesheuvel
2023-12-05 9:56 ` Marcin Juszkiewicz [this message]
2023-12-07 8:04 ` Ard Biesheuvel
2023-12-04 14:52 ` Gerd Hoffmann
2023-12-04 16:09 ` Ard Biesheuvel
2023-12-04 22:24 ` Gerd Hoffmann
2023-12-05 10:44 ` Alexander Graf via groups.io
2023-12-05 12:56 ` Gerd Hoffmann
2023-12-04 10:53 ` Gerd Hoffmann
2023-12-04 10:57 ` Ard Biesheuvel
2023-12-04 11:40 ` Gerd Hoffmann
2023-12-06 12:51 ` Gerd Hoffmann
2023-12-06 13:23 ` Ard Biesheuvel
2023-12-06 15:27 ` Gerd Hoffmann
2023-12-06 20:00 ` Taylor Beebe
2023-12-06 18:37 ` Oliver Smith-Denny
2023-12-07 7:59 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3edb6e4f-941e-4a69-a42f-304f3c1aafa6@linaro.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox