On Aug 8, 2013, at 3:17 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 07 Aug, at 02:10:28PM, Andrew Fish wrote: >> Well the issue I see is I don't think OS X or Windows are doing this. >> So I'm guessing there is some unique thing beings done on the Linux >> side and we don't have good tests to catch bugs in the EFI >> implementations. If the Linux loader hides the bugs and we don't hit >> them with other operating systems they are never going to get fixed. >> It would be good if we could track down some of these issues and make >> a request for some tests that can help catch these issues. The tests >> would be part of UEFI.org, but since some of us play in both worlds we >> can forward the known issues to the UEFI test work group. > > I'm all for helping to develop tests that catch these kind of bugs. > What's the next step? > I'll bring this up with UEFI.org. >> Is it possible to have a switch to turn off the not required behavior >> (hiding EFI implementation bugs) so that bad platforms could be >> detected? This would be a good thing to try on platforms at the >> upcoming UEFI Plugfest hosted by the Linux Foundation and the UEFI >> Forum, so the bad behavior can be detected and the vendors can fix the >> issue. > > We don't tend to provide switches for the kernel to turn off workarounds > because users run the risk of inadvertently stopping their machines from > booting correctly. Also, because the major distributions will always > enable the workarounds, the kernel would need to be built manually to > see any kind of informative error message. > > What we do have though is the Firmware Testsuite - fwts, > > https://wiki.ubuntu.com/Kernel/Reference/fwts > > I know that Brian (Cc'd) has been doing some excellent advocacy work, > getting people at plugfetsts to run this testsuite which tests for > implementation bugs from within a Linux environment. > >> PS Also maybe it would be possible to key this work around behavior on >> the EFI/UEFI version. So for example no work-around after UEFI v2.3.1? > > That would really depend on who has seen this bug and on which > platforms. Is there a particular reason that mapping the boot services > regions as-is would cause problems? > 1) The firmware bug could also be a security hole and thus needs to get fixed. 2) The kernel gets locked into a design that does not follow the specification, and this limits future design options. 3) Makes the code more complex to maintain and test. > -- > Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
