[edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable

[Laszlo Ersek]

On 1/6/23 10:55, Laszlo Ersek wrote:
> On 1/4/23 12:11, Gerd Hoffmann wrote:
> 
>> The versions are not that ancient.  The problem is more that upstream
>> grub is really slow on integrating patches so every distro does carry
>> a huge pile of downstream patches.  And they seem to re-introduce the
>> bug ...
> 
> See also: commit d20b06a3afdf ("OvmfPkg: disable no-exec DXE stack by
> default", 2015-09-15). That was more than seven years ago, and it's what
> 
>   git blame master -- OvmfPkg/OvmfPkgX64.dsc | grep PcdSetNxForStack
> 
> reports today.

On a more constructive note.

By the book, this guest OS-level quirk should be exposed from the
firmware up to libosinfo / osinfo-db.

Starting with a dynamic PCD or HOB exposed via fw_cfg (with the fw_cfg
filename conforming to "docs/specs/fw_cfg.rst" in QEMU), handled by
libvirtd and other management applications (domain XML and other config
formats, matching code, etc), and ultimately recorded in a "w^x"
capability entry in the libosinfo schema and the osinfo database.

All other guest OS compatibility settings are tracked in osinfo
nowadays, security related or not, and they are so important that recent
virt-install even refuses (by default) to install a domain if it doesn't
recognize (and the user doesn't say) what the guest OS is.

https://github.com/virt-manager/virt-manager/commit/26ecf8a5e3e4721488159605afd10e39f68e6382

Those settings control various CPU vulnerability mitigations even, IIUC,
so it's almost certainly the right place to implement this new quirk too.

Let us not sweep it under the carpet, and heap on more technical debt.
Storing grub hashes in the firmware is similar to Windows video drivers
tailoring themselves to the game the user happens to start. "Tailoring"
is fine, but not from the bottom up.

Here's what we could do for, and in, ArmVirtQemu *upstream*:

- file the proper RFEs for the above-described components,

- get their maintainers publicly commit to implementing them (that will
take a while),

- once each RFE has been committed to, and we think the whole picture is
covered, downgrade the "w^x" default in ArmVirtQemu as follows:

- list the ticket links near the code that does the downgrade

- *gate* the downgrade on the platform RTC reading a date that's before
a specific, open-coded constant. We'll forget about the downgrade, but
the RTC won't forget about time passing. This will make us revise the
concession in time (unlike how we've completely forgotten about
PcdSetNxForStack). Once all the RFEs have been fixed upstream, and
widely shipped in products, we can remove the downgrade.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#98098): https://edk2.groups.io/g/devel/message/98098
Mute This Topic: https://groups.io/mt/93922691/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-