Blah,<div>One repeated error here:</div><div>s/J\(M\)D/J\(M\)H/</div><div>BW<br><br><div class="gmail_quote">On Mon, Aug 6, 2012 at 9:33 PM, Brent Wallis <span dir="ltr"><<a href="mailto:brent.wallis@gmail.com" target="_blank">brent.wallis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi to All,<div><br></div><div>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.</div>
<div>;-)</div><div><br>
</div><div>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?</div><div><br></div><div>What I will try to do here is paraphrase a set of points from various authors and to make an initial 2 proposals.</div>
<div>(A personal habit is to use a persons initials...am sure you will work them out):</div>
<div><br></div><div>Preamble:</div><div>- Any press release has to be professionally handled. JT has laid out a standard press release format...well worth following.</div><div>- We have had an offer from a blogger to assist with the wording and further assist with pointers to method namely KR.</div>
<div><br></div><div>Proposal 1:</div><div>We ask KR to be scribe if we can come up with anything useful and pertinent.</div><div><br></div><div>What is the problem we need to highlight?:</div><div><br></div><div>Well its bloody complex to say the least. Any release needs to steer clear of the detail.</div>
<div>Distilling the issue into readable bites will be very, very, very hard!</div><div><br></div><div>- MC posted an excellent link from Matt Garrets LCA 2012 talk:</div><div><a href="http://www.youtube.com/watch?v=V2aq5M3Q76U&playnext=1&list=PL29F2E5E2064A6539&feature=results_main" target="_blank">http://www.youtube.com/watch?v=V2aq5M3Q76U&playnext=1&list=PL29F2E5E2064A6539&feature=results_main</a></div>
<div>The first 3/4 deals with design/ implementation issues and took all of my rusty OS101 studies to keep up.</div><div>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)</div>
<div><br></div><div><br></div><div>---UEFI is buggy </div><div>---UEFI is not DRM (and we should be very clear on that. DMCA could be used to remove any chance of effecting change)</div><div>---UEFI Secure boot could be seen as a distraction (the real issue being how buggy and bloated the current implementations are).</div>
<div>---UEFI Secure boot requires all drivers to be signed which will slow down open source innovation.</div><div>---Distro mods could become very difficult. eg Using Fedora as base for a specific linux appliance tuned for a specific task with specialised drivers.</div>
<div>---MS are way ahead of the game because they have been requiring signed drivers for 5 years. </div><div>---UEFI would be a useless distraction in virt platforms, it could be implemented but why? (which has also been pointed out by RC)</div>
<div>---UEFI secure boot is a reasonable idea in terms of security but...
</div>
<div>---No one really knows what hardware manufacturers are planning for UEFI.</div><div><br></div><div>- AN postulated that secure boot was about signed apps.</div><div>RC pointed out that this is probably not the case going forward.</div>
<div>This fits in with MGs point in the vid that UEFI is NOT DRM.</div><div><br></div><div>- AN in a second post has summarised a core issue highlited in MGs vid:</div><div><span style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">"...it looks like it won't ever be possible to boot Linux with</span><br style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">Secure Boot enabled, while retaining the freedom of being able to compile and</span><br style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">
<span style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">install your own kernel and/or modules."</span></div><div><br></div><div>- 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.</div>
<div><br></div><div>- AN in his first post laid out 3 position options:</div><div>"<span style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif">1. Secure Boot is bad and should not be allowed to go ahead in any form.</span></div>
<br style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif"><span style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif"> 2. Secure Boot could be bad so we must ensure it can be disabled if needed.</span><br style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif">
<br style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif"><span style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif"> 3. Secure Boot is great, providing we have control over the keys our</span><br style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif">
<span style="color:rgb(80,0,80);font-size:13.333333969116211px;font-family:arial,sans-serif"> equipment recognises as valid."</span><div><br></div><div>I can't find a comment that supports 1....and taking J(M)D's comment on board that option looks like a fail.</div>
<div>Option 2 has merit and it would but it would have a grave effect on freedom and Open Source innovation.</div><div>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.</div>
<div><br></div><div>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.</div><div>Specifically, we need to find out about how they plan to implement key control </div>
<div>and</div><div>How easy it will be for authorised users to implement options 2 and 3.</div><div><br></div><div>Proposal 2:</div><div>As a starting point, we craft a release that professionally,firmly and FAIRLY prods HW manufacturers for their UEFI plans.</div>
<div><br></div><div>Rgds</div><span class="HOEnZb"><font color="#888888"><div>BW</div><div><br></div><div><br></div>
</font></span></blockquote></div><br></div>