On Tue, Nov 26, 2019 at 1:20 PM Rich Persaud <persaur@gmail.com> wrote:
>
> On Nov 26, 2019, at 15:23, Andrew Cooper <Andrew.Cooper3@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
>
> <marmarek@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.
As one of those downstream users I have to say I like this A LOT!
> 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.
That's a good proposal, but the question, as always becomes who moves
the needle on this one so we avoid a sort of "tragedy of the commons"
type of situation.
Now, I'm not even talking about writing (and maintaining!) the actual
code -- but rather all the BD activities that would have to take place
to make it a reality. This actually may be a good question to ask
Linux Foundation since I've seen them be helpful in situations like
this.
> 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.
Yup! I could see this as well!
> 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.
Right -- because at the end of the day -- as I am discovering now,
there seems to be a non-trivial downstream constituency "curating"
those types of patches in separate silos (Project EVE included) it
would be great to at least have one central bucket (even if
non-default and protect by XXX_OPTION) for these patches to be curated
-- and that's upstream Xen.
Thanks,
Roman.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
signature.asc (0.48 KB)
