<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 9:10 PM, mrnuke <span dir="ltr"><<a href="mailto:mr.nuke.me@gmail.com" target="_blank">mr.nuke.me@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br><br>
[slightly OT, feel free to skip] My stance on blobs is a little weird. I try<br>
to make sure I have full control of my system. If the blob cannot do any harm<br>
to my freedom, or in other words, respects it, then that blob is acceptable.<br>
* For example, a hardwired boot blob which has been RE'd so that we know what<br>
it does and how it does it, would be acceptable (see Allwinner).</blockquote><div><br></div><div>Hard for me to agree with this, but if that's ok with you, it's ok with me. If you are claiming to understand</div>
<div>what an RE'd blob does then you've solved the halting problem, I think. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Even the FSF,<br>
according to RMS's own essays considers this to essentially be hardware.<br>
* A non-ISA (a) firmware blob which controls a piece of hardware which<br>
i) can only do one thing<br>
ii) without compromising the security of the system<br>
iii) and is non-essential for the functioning of the system<br>
is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs<br>
which would NOT be are ME (violates all three points), MRC (violates point<br>
iii, and potentially ii).<br></blockquote><div><br></div><div>Interesting. >From a security POV I'm a lot more worried about usb3 firmware than about the MRC. As far as </div><div>I'm concerned USB 3 firmware is a persistent embedded threat, violating point ii. The ME is of course far worse.</div>
<div>Of these I find the MRC the *least* threatening. </div><div><br></div><div>Laptops are little networked heterogeneous multicomputers. In many ways the code running on the main CPU is the least important bit. This is a big problem, getting worse, and nobody's thinking hard enough about it, because fixing it requires exposing more info than the vendors want you to have. Sound familiar? :-(</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* An ISA blob which is NOT essential for the bring-up of the system, and can<br>
reasonably be replaced by a free alternative. This basically includes VGA<br>
BIOSes.<br></blockquote><div><br></div><div>Makes no sense to me either. If the ISA blob is in place, then it's no different than MRC, save that</div><div>it is almost certainly persistent. In fact it's more dangerous than the ME. Until it's replaced, it can at any point compromise the security of the system.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > Additionally I heard claims, that the GPLv2 license is violated as it is<br>
> > currently impossible to rebuild the exact same image that is shipped<br>
> > with the devices as it is not even clear what commit was used to build<br>
> > the image and to my knowledge the requests on the list and in the IRC<br>
> > channel were not answered.<br>
><br>
> Dude, the commit is IN THE IMAGE. At least on the images I work with. As in:<br>
> ro bios version | Google_Link.2695.1.133<br>
><br>
[Again, feel free to skip ahead] I made some of the claims Paul is talking<br>
about.</blockquote><div><br></div><div>Well, you were wrong, and those are serious accusations. You should take a lot more care when you sling</div><div>that type of claim around. We've had to deal with it a lot in the past; some vendors dishonestly and repeatedly made that claim, knowing it was a lie, in order</div>
<div>to try to kill coreboot, more than once. They did not stop when we called them on it. It's pure FUD. It will almost certainly be revived again as a result of your claims and Paul's note, and we'll have to deal with it again. Thanks.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I have the git hash of the firmware which came with my chromebook, but<br>
a branch containing that hash is not available publicly. </blockquote><div><br></div><div><br></div><div>Baloney. Your not finding it does not mean it's not available. It means you didn't look hard enough. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
[Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a<br>
laptop that sells just shy of $200?<br></blockquote><div><br></div><div>You don't know what it cost them. You only know what it *might* cost you. Hence, this statement is almost certainly wrong. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is where I've been meaning to get to. I'm all for doing what the new<br>
title of this (hijacked) thread says: a new, modern long-term coreboot<br>
supported laptop which is "Respects Your Freedom" certifiable. A laptop that<br>
will become what the X60 is today.<br></blockquote><div><br></div><div>I'm wondering: what's wrong with the HP11? It goes much further today than any x86 laptop toward RYF. The MRC is source. There's no ME. The EC code is also open source. Why not start there? Sure, it's not coreboot; sure, it's not x86; who cares? It's totally RYF. And coreboot can run on it, I bet, if you care.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Chose the hardware. Set up a github temporary fork. Send me the hardware. I<br>
got Pomona, I got SPI, I got USB debug, and I got the burning desire to make<br>
this happen.<br></blockquote><div><br></div><div>I think that's wonderful, and you need to find a way to make it happen. Right now, as you have seen, laptop vendors are not breaking down the doors at AMD to use their chipsets in a laptop. There are reasons.</div>
<div></div></div><br></div><div class="gmail_extra">The volunteers need to lead this AMD effort, and the first step is finding the person to make it happen, and the next step is finding money.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">But, first, you really ought to make sure it's AMD you want, not ARM. And once you pick out a laptop, fill out the blob matrix, please, so we know what's going on.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Further, you need to make this scale. By the time you're done the first one, the laptop you choose will almost certainly no longer be sold. So you need to plan for, not just the first laptop, but the 2nd and 3rd and so on. Just doing it once has no value. That's one reason I keep advocating for starting with a chromebook; I have some idea of what it takes to do this, and a chromebook gives you a huge head start. I also understand the reasons you *don't* want to use chromebooks, however.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But if you took the huge amount of volunteer talent and effort that has been expended on obsolete thinkpads and old boards, and got it on this project, you could make it happen. Burn the boats!</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">ron</div></div>