Xen project Mailing List

On Nov 26, 2019, at 15:23, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> wrote:

On 26/11/2019 20:12, Roman Shaposhnik wrote:
On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, Nov 26, 2019 at 09:56:25AM -0800, Roman Shaposhnik wrote:
Hi Marek, after applying Jan's patch I'm making much further progress.
Xen boots fine and Dom0 seems to be OK (more tests are needed tho on
my end).

I'm attaching the logs from Xen and Dom0.

At this point it seems that adding efi=attr=uc is a better option for
these boxes than a wholesale efi=no-rs

Question #1: is this something that EFI_SET_VIRTUAL_ADDRESS_MAP was
supposed to cover by default (so I don't have to add efi=attr=uc)?
No, this looks like some different firmware (?) issue.

Question #2: is there any downside to *always* specifying efi=attr=uc?
Even for servers that, strictly speaking, don't need it?
TL;DR: It should be fine. It is what Linux does too.

Details:

Lets take a look why 'efi=attr=uc' helps, and how can we make it work
out of the box:

The issue is about memory marked as type=11 (EfiMemoryMappedIO) with
attr=8000000000000000 (EFI_MEMORY_RUNTIME). Indeed none of cachability
attribute is defined. For the record, defined attributes are (UEFI spec
.6):

   EFI_MEMORY_UC Memory cacheability attribute: The memory region supports
   being configured as not cacheable.

   EFI_MEMORY_WC Memory cacheability attribute: The memory region supports
   being configured as write combining.

   EFI_MEMORY_WT Memory cacheability attribute: The memory region supports
   being configured as cacheable with a “write through” policy.
   Writes that hit in the cache will also be written to main memory.

   EFI_MEMORY_WB Memory cacheability attribute: The memory region supports
   being configured as cacheable with a “write back” policy. Reads
   and writes that hit in the cache do not propagate to main memory.
   Dirty data is written back to main memory when a new cache line
   is allocated.

   EFI_MEMORY_UCE Memory cacheability attribute: The memory region supports
   being configured as not cacheable, exported, and supports the
   “fetch and add” semaphore mechanism.

My reading of UEFI spec doesn't give much hints what to do with memory
mappings without any cachability attribute. The only related info I've
found is about EfiMemoryMappedIO:

   This memory is not used by the OS. All system memory-mapped IO
   information should come from ACPI tables.

So, maybe there is some more info?

Anyway, if I understand correctly, MMIO region should be mapped as UC,
right?

I've also taken look at what Linux does. And basically, the only bit
Linux care about is EFI_MEMORY_WB - if it's absent, then set the region
as uncachable (page cache disabled bit in page table entry). So,
basically Linux by default does what Xen's efi=attr=uc does.
Very interesting! Thanks for doing the research.

So, to improve Xen's hardware/firmware compatibility, I have two ideas:

1. Make efi=attr=uc the default (it's still possible to disable it with
efi=attr=no).
I'd be very much in favor of that too (especially since it seems to match
Linux behaviour) What do others think?

Its more than just this. Linux also doesn't use EFI reboot because it
is broken almost everywhere (because Windows doesn't use it because its
broken almost everywhere, so it never gets fixed).

Xen should be following Linux, but I'm exhausted arguing this point.

A consequence is that downstream tend to share a pile of "unbreak Xen on
UEFI" patches which have been rejected upstream on philosophical rather
than technical grounds, despite this being a toxic environment to work in.

As an intermediate step, could we have an umbrella opt-in Kconfig option (CONFIG_EFI_NONSPEC_COMPATIBILITY?) that enables multiple EFI options for maximum hardware compatibility? For this thread and Xen 4.13, that would be EFI_SET_VIRTUAL_ADDRESS_MAP and efi=attr=uc. If more options/quirks are added in the future, downstreams using EFI_NONSPEC_COMPATIBILITY would get them by default.

The long-term solution is an OSS virtualization-security test tool (e.g. with Xen and QEMU KVM) that can be run by OEM/ODM QA factory teams on pre-production firmware and hardware. That is the most OEM-actionable development window where firmware quality issues can be detected and fixed. Microsoft's hardware logo/certification work with Windows 10 OEMs on "secured core" features is also tackling firmware improvements for virtualization-based security.

From the business side, Dell/HP/Lenovo + other OEMs and ODMs could add premium "FirmCare" SKUs into their custom build ordering systems, where customers could pay a small fee for additional firmware support, custom root-of-trust (e.g. BootGuard) key management, or even coreboot. This could move from cost-center incentives [1] to high-margin incentives [2] for firmware and platform health, safety & security. Another step would be including firmware requirements in supply chain contracts [3] for large customer orders.

While we wait on these ecosystem improvements, CONFIG_EFI_NONSPEC_COMPATIBILITY or a similar option for Xen 4.13 would help users of existing platforms.

Rich

[1] Firmware is the new Software, https://www.platformsecuritysummit.com/2018/speaker/hudson/

[2] https://i.blackhat.com/USA-19/Thursday/us-19-Krstic-Behind-The-Scenes-Of-IOS-And-Mas-Security.pdf

[3] "Humans" videos and Q&A, https://www.platformsecuritysummit.com/2019/videos/

Re: [Xen-devel] UEFI support on Dell boxes (was: Re: Status of 4.13)