A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)
On Monday, March 24, 2014 05:00:26 PM ron minnich wrote:
I keep wanting to drop out of this discussion but there are some things I just can't let go by,
Let's focus on constructicism then (if that is even a word).
On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel <
paulepanter@users.sourceforge.net> wrote:
First I find "wildest expectations" a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult.
[...]
We don't like it. But if the choice is to ship on nothing, or ship with blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look at the big picture, because we still don't have EC source on those boxes. The OLPC shipped with blobs. This is not a simple problem.
[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). 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). * 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.
(a) I define an ISA blob to be a blob which contains instructions for the main CPU's architecture, and executes such instructions on the main CPU. Microcode would be a non-ISA blob, as it is not a set of x86 (or ARMv7) instructions, despite it residing in the main CPU.
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. I have the git hash of the firmware which came with my chromebook, but a branch containing that hash is not available publicly. This is one of the reasons I proposed to allow merging branches from shipping firmware rather than forcing a rebase of all patches.
For Google and the laptop vendors, I guess the goal is simply to save
[Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a laptop that sells just shy of $200?
the money per device that traditionally went to the BIOS/UEFI vendors.
You should not impute motive where you have no knowledge [...]
A very tempting point, but I'll stay out of it.
In my opinion, we should get the first AMD laptop supported as soon as possible
yes, well, I've been asking for help on this for some time, years in fact, but I can't do it all myself. It's part of my huge disappointment that our volunteers chose to put their time into (quite obsolete, no longer manufactured) X and T thinkpads instead of something modern and open. You can fault Google for their decision to go with Intel; but the volunteers have not done a lot better, in fact worse in my view. Frankly, it's a disappointment.
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 don't have the financials to do this by myself. I don't have the time to do this by myself, and most certainly not the experience to provide an A to Z turnkey solution. I'm glad you asked. Carl-Daniel asked as well. He did a few months ago, and is still in the process of choosing a good candidate. There aren't many that are both durable _and_ RYF-certifiable after our port is made.
I am willing to invest whatever limited time, limited knowledge, and limited experience I have into making this project happen.
One option here is to focus less on the things you currently put your time on, and focus more on getting that AMD laptop working, eh? Because it's easy to talk about what we should do. It's better to start DOING IT. And getting that AMD laptop going is a lot more important than fixing spelling errors in AGESA.
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.
Once we get the hardware in the hands of interested parties we can start actually DOING IT. There is no shortage of capable and interested individuals. We're just scattered across the internets with no clear direction, no leader, and no hardware.
Yeah, I hijacked the thread. I don't care. A modern LTS laptop is far more important than a theoretical rant-cussion about expectations. Sue me.
Still interested? I'll tell you my vision in more detail.
Alex
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke.me@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
On Mon, Mar 24, 2014 at 9:10 PM, mrnuke mr.nuke.me@gmail.com wrote:
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 like your attitude. See if there's a laptop that looks doable in the ~$500 range, buy two of 'em, and tell me how to reimburse you.
Note: $$$ would come from my own pocket and has nothing to do with my employer. Note 2: This might be a good place to start: https://chromium-review.googlesource.com/#/c/188275/
* mrnuke mr.nuke.me@gmail.com [140325 05:10]:
- 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). 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).
The ME is a non-ISA firmware blob. It's more like EC firmware, a piece of software running on a completely different processor. It just happens to share the SPI flash with the main CPU.
USB3 blobs can do more than one thing and violate security, just as any other blob.
MRC is an ISA blob.
- 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.
VGA oproms can about as reasonably be replaced as MRC. (within an order of magnitude or so of effort). Both of them can be considered non-essential. You can run out of cache just as much as you can run without video. The differenciation is rather arbitrary.
[Again, feel free to skip ahead] I made some of the claims Paul is talking about. I have the git hash of the firmware which came with my chromebook, but a branch containing that hash is not available publicly.
Yes it is. Check out the chromium repository. It has a public firmware branch for each released platform.
Stefan
-
David Hendricks -
mrnuke -
ron minnich -
Stefan Reinauer