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

Brent Wallis brent.wallis at gmail.com
Mon Aug 6 21:33:05 EST 2012

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

- 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:
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

---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
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

- 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

   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
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux.org.au/pipermail/linux-aus/attachments/20120806/5935f1c8/attachment.htm 

More information about the linux-aus mailing list