[Linux-aus] UEFI Secure Boot - Precis of List Comments and proposals

[Brent Wallis]

Blah,
One repeated error here:
s/J\(M\)D/J\(M\)H/
BW

On Mon, Aug 6, 2012 at 9:33 PM, Brent Wallis <brent.wallis at gmail.com> wrote:

> Hi to All,
>
> Well I started this, and , after spending the last couple of hours going
> through some of the valuable list comments and links , am starting to feel
> I may regret it.
> ;-)
>
> Let me preface this by pointing out that this list is a really hard way to
> collaborate....perhaps a better mechanism for future endeavours can be
> worked on later?
>
> What I will try to do here is paraphrase a set of points from various
> authors and to make an initial 2 proposals.
> (A personal habit is to use a persons initials...am sure you will work
> them out):
>
> Preamble:
> - Any press release has to be professionally handled. JT has laid out a
> standard press release format...well worth following.
> - We have had an offer from a blogger to assist with the wording and
> further assist with pointers to method namely KR.
>
> Proposal 1:
> We ask KR to be scribe if we can come up with anything useful
> and pertinent.
>
> What is the problem we need to highlight?:
>
> Well its bloody complex to say the least. Any release needs to steer clear
> of the detail.
> Distilling the issue into readable bites will be very, very, very hard!
>
> - MC posted an excellent link from Matt Garrets LCA 2012 talk:
>
> http://www.youtube.com/watch?v=V2aq5M3Q76U&playnext=1&list=PL29F2E5E2064A6539&feature=results_main
> The first 3/4 deals with design/ implementation issues and took all of my
> rusty OS101 studies to keep up.
> But, there are some excellent, really easy to understand takeaways, in the
> last 1/4 and questions.(suggest a jump to there for the less kernel
> inclined)
>
>
> ---UEFI is buggy
> ---UEFI is not DRM (and we should be very clear on that. DMCA could be
> used to remove any chance of effecting change)
> ---UEFI Secure boot could be seen as a distraction (the real issue being
> how buggy and bloated the current implementations are).
> ---UEFI Secure boot requires all drivers to be signed which will slow down
> open source innovation.
> ---Distro mods could become very difficult. eg Using Fedora as base for a
> specific linux appliance tuned for a specific task with specialised drivers.
> ---MS are way ahead of the game because they have been requiring signed
> drivers for 5 years.
> ---UEFI would be a useless distraction in virt platforms, it could be
> implemented but why? (which has also been pointed out by RC)
> ---UEFI secure boot is a reasonable idea in terms of security but...
> ---No one really knows what hardware manufacturers are planning for UEFI.
>
> - AN postulated that secure boot was about signed apps.
> RC pointed out that this is probably not the case going forward.
> This fits in with MGs point in the vid that UEFI is NOT DRM.
>
> - AN in a second post has summarised a core issue highlited in MGs vid:
> "...it looks like it won't ever be possible to boot Linux with
> Secure Boot enabled, while retaining the freedom of being able to compile
> and
> install your own kernel and/or modules."
>
> - As J(M)D has pointed out, this  issue is NOT going to go away and that
> there are coders looking at workarounds that keep to the core security
> principle.
>
> - AN in his first post laid out 3 position options:
> "1. Secure Boot is bad and should not be allowed to go ahead in any form.
>
>    2. Secure Boot could be bad so we must ensure it can be disabled if
> needed.
>
>    3. Secure Boot is great, providing we have control over the keys our
>       equipment recognises as valid."
>
> I can't find a comment that supports 1....and taking J(M)D's comment on
> board that option looks like a fail.
> Option 2 has merit and it would  but it would have a grave effect on
> freedom and Open Source innovation.
> Option 3 has merit as well, but if UEFI is buggy, bloated and too complex
> (complexity points made by RC) it could have the same affect as option 2.
>
> IMHO, the first step in what will probably be a very long road is to find
> out what Hardware Manufacturers are going to do with UEFI.
> Specifically, we need to find out about how they plan to implement key
> control
> and
> How easy it will be for authorised users to implement options 2 and 3.
>
> Proposal 2:
> As a starting point, we craft a release that professionally,firmly and
> FAIRLY prods HW manufacturers for their UEFI plans.
>
> Rgds
> BW
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/linux-aus/attachments/20120806/b9f3aff4/attachment.htm