On 12/01/2023 17:58, Laszlo Ersek wrote:
The case is that both QEMU and edk2 check for each other's supported
features. It's a complex interwoven feature set with security
impact, which is exactly why we added feature negotiation at every
step -- effectively mutual negotiation wherever necessary. I cannot
claim I remember every part of it, and playing tricks around feature
negotiation with SMM impact makes me *extremely uncomfortable*. I
absolutely don't want to author an OVMF patch, briefly before I
disappear again (for good!), that "looks good" now, and then becomes
a horrible SMM CVE in a year or two. I want to go for "obviously no
bug", rather than "no obvious bug".
I'm definitely not sufficiently familiar with all of the QEMU and OVMF
historical quirks to safely author or review a patch to cover all of
this, so I will very definitely defer to your judgement on this.
On 12/01/2023 18:22, Laszlo Ersek wrote:
There's got to be a limit to how far we try to compensate for broken
(virtual) hardware. :( The right thing to do is to wait for the QEMU
patch to reach as many as possible stable branches, let the distros
pick up the new stable releases, and then merge the hardliner hang.
I concur.
Thanks for considering the suggestion! :)
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98393): https://edk2.groups.io/g/devel/message/98393
Mute This Topic: https://groups.io/mt/96218818/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
