On Nov 26, 2019, at 15:23, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 26/11/2019 20:12, Roman Shaposhnik wrote: >>> On Tue, Nov 26, 2019 at 10:32 AM Marek Marczykowski-Górecki >>> <marma...@invisiblethingslab.com> 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/
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
