On Nov 27, 2019, at 04:16, Jan Beulich <jbeul...@suse.com> wrote: > > On 26.11.2019 22:20, Rich Persaud wrote: >> 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. > > While I don't particularly like it, I'd be okay with having such > an option, provided it doesn't hamper code readability too much. > However - why would you stop at those two things? Why not also > exclude reboot through UEFI (as indicated by Andrew), or use of > runtime services as a whole? What about /mapbs? The fundamental > problem I see here really is - where would we draw the line?
If we take this thread as an example, a middle ground was found among developers motivated to maintain the workarounds for downstream projects with affected hardware. Qubes, EVE & OpenXT are used on edge/client devices that often have (relative to servers) a shorter lifetime, with more device churn and support costs. These two initial options would address current pain points and enable the use of upstream Xen + EFI RS on more devices, e.g. for OTA updates with forward-sealed integrity measurements. The line could change if more downstreams adopt the option and/or new devices appear that have both customer adoption and problematic firmware behavior. Rich _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
