Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 19 Aug, at 09:09:54PM, David Woodhouse wrote: 3. Even if we can't *remove* the code, sometimes we can disable it at runtime if we detect the BIOS is new enough that it shouldn't be broken. Yes, this is definitely something we should be looking to implement. It seems likely to me that we're eventually going to start hitting issues supporting the latest UEFI firmware because of the workarounds we're currently carrying in the kernel. The EDKII folks are surprised time and time again to hear of the hoops we jump through in the kernel to support buggy implementations. It's only going to be a matter of time until we *have* to disable some our workarounds in order to boot the most recent incarantions of UEFI. Not least because carrying these workarounds unconditionally and indefinitely severely limits our ability to innovate. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote: All, The Linux Foundation and The UEFI Forum are hosting a UEFI Plugfest event in New Orleans on September 19-20, 2013. This event will run concurrent with Linux Plumbers Conference, just after LinuxCon at the Hyatt Regency New Orleans. Hm. It would be really useful to have a kernel build option which *disables* all the workarounds we've ever put in for broken firmware. Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. And there's a school of thought that says we should brick as many Samsung machines as possible, if they actually turn up without having fixed that. A stress test for the NV storage is actually a really good idea... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. Why? It's not like we can ever stop carrying that code. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Hm. It would be really useful to have a kernel build option which *disables* all the workarounds we've ever put in for broken firmware. Yeah, cool! I wonder if we could reach a high double-digit percentage of machines not booting/barfing on such a clean kernel. While at it, can we please replace the fw with coreboot? :-) Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. And there's a school of thought that says we should brick as many Samsung machines as possible, Yep, and there's the rooted secure boot asus f*ckup which we should also advertize while booting, enabling people to use it: https://www.blackhat.com/us-13/archives.html#Bulygin /me LOLs ominously... -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. Why? It's not like we can ever stop carrying that code. The reason for doing it is that we have a buildable reference implementation that's fully spec compliant we can then make the basis of a test suite for UEFI. I am worried about it from another angle, though: history has shown we're not very good at maintaining configurations which we don't really use ... since every distro will turn this off (or the workarounds on), it's going to be a bit of work for someone to make sure it still functions. James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote: On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. Why? It's not like we can ever stop carrying that code. The reason for doing it is that we have a buildable reference implementation that's fully spec compliant we can then make the basis of a test suite for UEFI. And why's that a benefit? Nobody's ever going to be able to ship an OS that doesn't implement these workarounds - they're de-facto part of the spec. It'd make more sense to document them officially. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 2013-08-19 at 17:00 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 08:22:45AM -0700, James Bottomley wrote: On Mon, 2013-08-19 at 13:55 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 09:25:35AM +0100, David Woodhouse wrote: Every deviation from the spec (or common sense), however minor, should show up as a clear failure. Even the ones we *have* been able to work around, because we still want them *fixed*. Why? It's not like we can ever stop carrying that code. The reason for doing it is that we have a buildable reference implementation that's fully spec compliant we can then make the basis of a test suite for UEFI. And why's that a benefit? Nobody's ever going to be able to ship an OS that doesn't implement these workarounds - they're de-facto part of the spec. It'd make more sense to document them officially. The object of having a test suite conform to the spec is not to perpetuate the cockups that occurred in round one of the implementation and to force everyone to pay closer attention to what the spec says. Otherwise the amount of workarounds is just going to grow without bounds. James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote: The object of having a test suite conform to the spec is not to perpetuate the cockups that occurred in round one of the implementation and to force everyone to pay closer attention to what the spec says. Otherwise the amount of workarounds is just going to grow without bounds. There's a benefit in having a test suite that prevents new errors from being introduced, but there's no benefit in failing on errors that we have to work around anyway. We have the code. We're never going to be able to remove the code. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 2013-08-19 at 18:21 +0100, Matthew Garrett wrote: On Mon, Aug 19, 2013 at 10:02:55AM -0700, James Bottomley wrote: The object of having a test suite conform to the spec is not to perpetuate the cockups that occurred in round one of the implementation and to force everyone to pay closer attention to what the spec says. Otherwise the amount of workarounds is just going to grow without bounds. There's a benefit in having a test suite that prevents new errors from being introduced, but there's no benefit in failing on errors that we have to work around anyway. We have the code. We're never going to be able to remove the code. It's not about us removing the code, it's about us having an accurate compliance test. There are two reasons for having a fully correct compliance test 1. Our work arounds have unintended consequences which have knock on effects which mean that you don't know if a test failure is real or an unintended consequence of a work around. 2. New features in specs tend to build on previous features, so we're going to have a hard time constructing accurate tests for layered features where we've done a work around for the base feature. James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 10:38:46AM -0700, James Bottomley wrote: It's not about us removing the code, it's about us having an accurate compliance test. There are two reasons for having a fully correct compliance test 1. Our work arounds have unintended consequences which have knock on effects which mean that you don't know if a test failure is real or an unintended consequence of a work around. It doesn't matter. If a platform is supposed to run Linux 3.6 then it has to run Linux 3.6 regardless of whether or not the failure is due to a firmware bug or a bug in the kernel. The platform vendor will be obliged to fix it in the firmware no matter what the test suite says. 2. New features in specs tend to build on previous features, so we're going to have a hard time constructing accurate tests for layered features where we've done a work around for the base feature. Which is easily rectified if the specification is modified to describe reality instead. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 2013-08-19 at 10:38 -0700, James Bottomley wrote: It's not about us removing the code, it's about us having an accurate compliance test. There are two reasons for having a fully correct compliance test 1. Our work arounds have unintended consequences which have knock on effects which mean that you don't know if a test failure is real or an unintended consequence of a work around. 2. New features in specs tend to build on previous features, so we're going to have a hard time constructing accurate tests for layered features where we've done a work around for the base feature. 3. Even if we can't *remove* the code, sometimes we can disable it at runtime if we detect the BIOS is new enough that it shouldn't be broken. Do we really want to declare that we can only use 50% of the available NV storage space for *ever* more, just because some muppet thought they could squeeze some non-upstream value add into their implementation of the flash management? You seem to be suggesting that we should retrospectively write that limitation into the UEFI spec, which is a completely insane suggestion. We absolutely want to be able to draw a line under it and declare that any firmware built after $SOMEDATE is expected to be fixed, so we don't have to do these stupid workarounds, and we can make full use of the available space. This type of model gets used for Windows all the time, doesn't it? Especially with ACPI, they base some of their behaviour on the date that the BIOS claims to be built, and only use newer features if it's new enough that they're expected to be working? 4. We don't want people turning up to a plugfest with a buggy pile of crap that we just *happen* to have worked around already, and going back to their company with a happy no problems discovered report, and thinking that they are doing a good job. If they turn up with a buggy pile of crap, we want to make sure they *know* it's a buggy pile of crap — they need to be sent home with their tail between their legs with a clear message that they need to do better in future. And that will *help* to avoid future bugs, hopefully. The point of a plugfest is *not* just to gather a torture test together and force the kernel developers to find a consistent set of workarounds for *every* pathological brokenness out there. We could do that with a big credit card and a buying spree of random machines. Of *course* we should also do the tests with a fully-workarounded kernel and be able to ensure that our kernel can boot on existing machines. But that's a separate issue. That's about *us* learning and improving. But it does need to work *both* ways for all parties to get the maximum benefit. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 09:09:54PM +0100, David Woodhouse wrote: Do we really want to declare that we can only use 50% of the available NV storage space for *ever* more, just because some muppet thought they could squeeze some non-upstream value add into their implementation of the flash management? You seem to be suggesting that we should retrospectively write that limitation into the UEFI spec, which is a completely insane suggestion. We only reserve 3K now, and testing this in the existing UEFI test kit would be entirely achievable. Including the ability to remove this check from the kernel is just an invitation for someone to build a kernel without it and then be surprised when their machine fucks up. We absolutely want to be able to draw a line under it and declare that any firmware built after $SOMEDATE is expected to be fixed, so we don't have to do these stupid workarounds, and we can make full use of the available space. We have no way to guarantee that. Most board vendors don't turn up to the plugfests and aren't going to run anything we ship. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 09:21:11PM +0100, David Woodhouse wrote: On Mon, 2013-08-19 at 21:19 +0100, Matthew Garrett wrote: We have no way to guarantee that. Most board vendors don't turn up to the plugfests and aren't going to run anything we ship. Oh well, let's just wring our hands and not bother to turn up to the plugfest at all then. No point trying to *improve* the situation, after all. The plugfests have, from our perspective, always been useful in identifying new implementation interpretations before hardware ships. But even then, it's usually too late to modify the firmware. Vendors who care about Linux compatibility have already tested Linux before we turn up. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, 2013-08-19 at 21:39 +0100, Matthew Garrett wrote: The plugfests have, from our perspective, always been useful in identifying new implementation interpretations before hardware ships. But even then, it's usually too late to modify the firmware. Vendors who care about Linux compatibility have already tested Linux before we turn up. You effectively seem to be suggesting that nothing will ever get better on the UEFI side, and the only benefit of the plugfest is that we get to see the latest brokenness and try to come up with a workaround for it before the consumers are afflicted with it? That's a really pessimistic view, and I'd really like us to be a little more optimistic. Things can't be, or at least can't *stay*, that bad. Surely? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature
Re: UEFI Plugfest 2013 -- New Orleans
On Mon, Aug 19, 2013 at 10:06:51PM +0100, David Woodhouse wrote: You effectively seem to be suggesting that nothing will ever get better on the UEFI side, and the only benefit of the plugfest is that we get to see the latest brokenness and try to come up with a workaround for it before the consumers are afflicted with it? Pretty much. There's a decent chance that board vendors already have the broken code before we end up testing against it. That's a really pessimistic view, and I'd really like us to be a little more optimistic. Things can't be, or at least can't *stay*, that bad. Surely? Most vendors don't care about testing against Linux, and we can't make them care. What they're more likely to test against is the SCT, and extending that to cover a wider range of test cases (such as exhausting variable space) is much more likely to result in things being caught before anything is shipped - but even then, board vendors are going to take IBV code, perform value add, never run a test suite and just make sure it boots Windows. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UEFI Plugfest 2013 -- New Orleans
On Fri, 2013-08-16 at 11:20 -0400, John W. Linville wrote: Participants in this event must join the UEFI at the Adopter level or above (gratis): http://www.uefi.org/join Just a note on doing this. I did it today using the three page form on the uefi web page: you can fill it in on your computer using gimp and then just email the completed form to ad...@uefi.org. They had mine turned around in a few hours (but I wouldn't rely on that for a last minute registration). James -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
