[coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)

[ron minnich]

On Mon, Mar 24, 2014 at 9:10 PM, mrnuke <mr.nuke.me at gmail.com> wrote:

>
>
>
> [slightly OT, feel free to skip] My stance on blobs is a little weird. I
> try
> to make sure I have full control of my system. If the blob cannot do any
> harm
> to my freedom, or in other words, respects it, then that blob is
> acceptable.
>  * For example, a hardwired boot blob which has been RE'd so that we know
> what
> it does and how it does it, would be acceptable (see Allwinner).


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
what an RE'd blob does then you've solved the halting problem, I think.

Even the FSF,
> according to RMS's own essays considers this to essentially be hardware.
>  * A non-ISA (a) firmware blob which controls a piece of hardware which
>   i) can only do one thing
>   ii) without compromising the security of the system
>   iii) and is non-essential for the functioning of the system
> is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs
> which would NOT be are ME (violates all three points), MRC (violates point
> iii, and potentially ii).
>

Interesting. From a security POV I'm a lot more worried about usb3 firmware
than about the MRC. As far as
I'm concerned USB 3 firmware is a persistent embedded threat, violating
point ii. The ME is of course far worse.
Of these I find the MRC the *least* threatening.

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



>  * An ISA blob which is NOT essential for the bring-up of the system, and
> can
> reasonably be replaced by a free alternative. This basically includes VGA
> BIOSes.
>

Makes no sense to me either. If the ISA blob is in place, then it's no
different than MRC, save that
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.


>
> > > Additionally I heard claims, that the GPLv2 license is violated as it
> is
> > > currently impossible to rebuild the exact same image that is shipped
> > > with the devices as it is not even clear what commit was used to build
> > > the image and to my knowledge the requests on the list and in the IRC
> > > channel were not answered.
> >
> > Dude, the commit is IN THE IMAGE. At least on the images I work with. As
> in:
> > ro bios version | Google_Link.2695.1.133
> >
> [Again, feel free to skip ahead] I made some of the claims Paul is talking
> about.


Well, you were wrong, and those are serious accusations. You should take a
lot more care when you sling
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
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.


I have the git hash of the firmware which came with my chromebook, but
> a branch containing that hash is not available publicly.



Baloney. Your not finding it does not mean it's not available. It means you
didn't look hard enough.


>
> [Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a
> laptop that sells just shy of $200?
>

You don't know what it cost them. You only know what it *might* cost you.
Hence, this statement is almost certainly wrong.


> This is where I've been meaning to get to. I'm all for doing what the new
> title of this (hijacked) thread says: a new, modern long-term coreboot
> supported laptop which is "Respects Your Freedom" certifiable. A laptop
> that
> will become what the X60 is today.
>

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.


> Chose the hardware. Set up a github temporary fork. Send me the hardware. I
> got Pomona, I got SPI, I got USB debug, and I got the burning desire to
> make
> this happen.
>

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.

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.

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.

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.

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!

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140324/973a6136/attachment-0001.html>