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:
http://www.uefi.org/events
Participants in this event must join the UEFI at the Adopter level or
above (gratis):
http://www.uefi.org/join
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
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
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 [email protected]. They had mine
turned around in a few hours (but I wouldn't rely on that for a last
minute registration).
James
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
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 | [email protected]
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.
--
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
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 | [email protected]
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
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 | [email protected]
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
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 | [email protected]
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
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 | [email protected]
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.
--
dwmw2
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 | [email protected]
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
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 | [email protected]
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