UEFI Plugfest 2013 -- New Orleans
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.
This event is intended to provide the Linux community with an opportunity to conduct interoperability testing with a variety of UEFI implementations. Additionally, the event will feature technical presentations related to UEFI advancements and key technology insights.
More information is available from the UEFI Events page:
Participants in this event must join the UEFI at the Adopter level or above (gratis):
Registration for this event is available here:
https://www.regonline.com/register/login.aspx?eventID=1219264&MethodId=0&EventsessionId=
Registration closes on Sunday, September 1, 2013 -- don't delay!
Thanks,
John
Signature · 2 lines
John W. Linville Someday the world will need a hero, and you [email protected] might be all we have. Be ready.
Quoted 4 lines · John W. Linville
Participants in this event must join the UEFI at the Adopter level or above (gratis):
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 admin-n+FAgK7Axi/[email protected] They had mine turned around in a few hours (but I wouldn't rely on that for a last
minute registration).
James
Quoted 6 lines · John W. Linville
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...
Signature · 1 line
dwmw2
Quoted 3 lines · David Woodhouse
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 7 lines · Matthew Garrett
Quoted 3 lines · David Woodhouse
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
Quoted 7 lines · James Bottomley
Quoted 6 lines · Matthew Garrett
Quoted 3 lines · David Woodhouse
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*.
Quoted 5 lines
Quoted 1 line
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 10 lines · Matthew Garrett
Quoted 9 lines · James Bottomley
Quoted 7 lines · Matthew Garrett
Quoted 3 lines · David Woodhouse
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.
Quoted 7 lines
Quoted 3 lines
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
Quoted 5 lines · James Bottomley
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 8 lines · Matthew Garrett
Quoted 5 lines · James Bottomley
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.
Quoted 4 lines
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
Quoted 7 lines · James Bottomley
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.
Quoted 4 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · James Bottomley
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.
Signature · 1 line
dwmw2
Quoted 6 lines · David Woodhouse
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.
Quoted 4 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 3 lines · Matthew Garrett
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.
Signature · 1 line
dwmw2
Quoted 8 lines · David Woodhouse
Quoted 3 lines · Matthew Garrett
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 5 lines · Matthew Garrett
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?
Signature · 1 line
dwmw2
Quoted 4 lines · David Woodhouse
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.
Quoted 3 lines
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.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 11 lines · Matthew Garrett
Quoted 8 lines · David Woodhouse
Quoted 3 lines · Matthew Garrett
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.
Quoted 6 lines
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.
Even if most vendors never bother testing at all, and even if a good number of those that do use only the SCT and it hopefully gets extended to check more things, for the ones who do care I feel having a 'disable all workarounds' option would be useful.
Having multiple *independent* implementations, all verifying for both interoperability (workarounds enabled) and correctness (workarounds disabled) is *exactly* what plugfests are intended to do.
Coming to a plugfest and saying "Well, *my* code runs fine, but I'm not going to tell you whether you're 'doing it right' or just 'doing it wrong in a way we already know about'" is rather rude.
Quoted 2 lines · David Woodhouse
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.
Signature · 1 line
Matt Fleming, Intel Open Source Technology Center
Quoted 2 lines · David Woodhouse
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? :-)
Quoted 6 lines
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...
Signature · 5 lines
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--