linux-kernel - Re: UEFI Plugfest 2013 -- New Orleans

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1376942994.2322.39.camel@shinybook.infradead.org>
Date:	Mon, 19 Aug 2013 21:09:54 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"John W. Linville" <linville@...driver.com>,
	linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: 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

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)