On Tuesday, March 25, 2014 12:03:28 PM David Hendricks wrote:
> On Tue, Mar 25, 2014 at 10:57 AM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
> > On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote:
> > > Just one thing. Don't underestimate just how miserable the EC can make
> > > your life. I place a high premium on systems with an open EC. Just be
> > > careful there.
> >
> > Can you tell us more about the Samsung Chromebook 2?
>
> What do you want to know? It's been announced, the specs are out, the
> firmware code is out in the open (it ships with u-boot), and we even have
> some code upstream for it in coreboot that could be polished up. There's
> the usual masked ROM in addition to the 8KB BL0 blob, but everything else
> is open including the EC firmware.
>
I'm assuming BLO is not persistent.
> It's a nice laptop that is probably already a good candidate for RYF. I'll
> leave subjective analysis as an exercise for the reader.
Teardown pictures? Construction quality? Shelf life? Performance numbers?
As far as RYF, it's by far the best candidate with the least amount of work
involved. Bonus: no proprietary OS and/or IBV taxes. I don't know if Google
charges OEMs anything for the use of its software, but if it does, that money
goes to FLOSS, so it's a non-issue.
Alex
* ron minnich <rminnich(a)gmail.com> [140325 06:34]:
>
>
>
> On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko <
> phcoder(a)gmail.com> wrote:
>
>
> I don't see how this prevents any of my propositions for the bulk of the
> boards. The problem you describe isn't going away with your proposition.
> We still want to have a top which is supposed to work on all boards.
>
>
>
> All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All
> boards? Are you sure?
Keeping old boards in a branch of coreboot that is not moving as fast as
upstream will reduce breakage and stabilize the code base for those
systems.
Stefan
On Monday, March 24, 2014 10:31:49 PM ron minnich wrote:
> On Mon, Mar 24, 2014 at 9:10 PM, mrnuke <mr.nuke.me(a)gmail.com> wrote:
> > * 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.
>
I know what the Allwinner BROM does, I know it will go into a special USB mode
if the boot fails, and that mode has the capability to inject and executw
arbitrary code via USB OTG, and can also modify contents of NAND, MMC, SPI
flash, etc. Does that kill any hopes of security? Yes. Does it maky any less
free? No.
> > * 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
>
> 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.
I guess that depends on how capable the USB3 micro is. But OK, USB3 firmware
is not accepted for the purpose of this conversation.
> > * 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.
>
The idea is that the system be RYF capable. This doesn't mean it can be RYF
with such blobs. If replacing these blobs is reasonably doable by a group of
non-commercial guys, then we consider this a non-issue in the context of
picking a hardware candidate. Simply put, these blobs should be replaceable in
the medium term, so the system can be brought to a RYF state. A VGA BIOS meets
these weird criteria. (I did say my views on blobs are weird, didn't I?)
> > 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.
>
I call baloney on this one. I do not have to "look hard enough". Section 3
defines how hard I should look. My chromebook came with no corresponding
source code, and no written offer for the source code. So no, I don't have to
jailbreak the device to get to a root shell, read the flash, dd the BIOS_STUB
out of there, and run cbfstool to extract the .config in order to find out I'm
running coreboot commit ff1f4757e4bd35a6b72018d0982b5e2bec89a1bb
Did I mention the manufacturer (the one whose name was on the box) explicitly
responded to my request for source code with "we don't give that away"?
> > 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.
>
It won't be available for purchase much longer, and it's not very practical as
a day to day laptop due to its tiny screen. A lot of drawbacks, but sure, it
is a valid candidate nonetheless.
Carl-Daniel was flinging the idea of a laptop with long shelf life. He found
something just recently IIRC. Not cheap, but supposedly sturdy and with an
expected shelf like of at least 2 more years.
Oh yeah, can you tell us anything about the Samsung Chromebook 2?
> > 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.
>
Yeah. AMD parts usually end up in cheap laptops that are not expected to stay
in one piece for more than a month. Although performance-wise, I still miss my
old AMD laptop.
> 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.
>
Exynos still has that annoyng BL0 blob, does it not? It's either a trade-off
or a trade-off. Damn!
> 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.
Yeah, I don't like this either. However, if people are willing to use an
ancient laptop for the sake of RYF, then that's a niche we'd like to modernize
a bit. Yeah, the same people that put money in the pockets of OS vendors and
IBVs; it's why I don't like it.
There'd probably be a lot more I'd say here if you hadn't brought up those
darn HP11 s. :)
> I also understand the reasons you *don't* want to use chromebooks, however.
>
I did not disqualify ARM chromebooks. I just want to make sure all good
candidates are given a proper chance. Is a big shiny screen and a beefy CPU
with IGP that can play Xonotic (formerly Nexuiz) worth the porting effort?
That's a point which needs proper consideration.
> 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!
>
Vladimir?
Alex
On Tuesday, March 25, 2014 10:53:51 AM ron minnich wrote:
> Just one thing. Don't underestimate just how miserable the EC can make your
> life. I place a high premium on systems
> with an open EC. Just be careful there.
>
Can you tell us more about the Samsung Chromebook 2?
Alex
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(a)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 03/25/2014 02:00 AM, ron minnich wrote:
> I keep wanting to drop out of this discussion but there are some things I
> just can't let go by,
>
>
> On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel <
>
>> 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
>
> from chrome:system on my link. I also just checked my falco and the hash is
> right there too from cbmem -c.
> I don't build all platforms; have you found some where this is not the
> case? Might you consider fixing it?
>
Hi Ron
I made these claims about old samsung/lumpy units late in 2012, back
then the repositories at Chromium git were not even open to public.
I do not have collection of Chromebooks either, so you can consider all
this discussion as unreliable second-hand knowledge, should you wish to
do so. Here are my notes about recent discussion on #coreboot.
Hardware in question is: C710-2834, google/parrot
hexdump -C shipped_parrot.rom | tail
007fff60 00 00 47 4f 4f 47 4c 45 00 50 61 72 72 6f 74 00
|..GOOGLE.Parrot.|
007fff70 9f 00 00 00 9e 00 00 00 97 00 00 00 00 00 10 00
|................|
007fff80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
cbmem -c
coreboot- Mon Apr 29 15:07:52 PDT 2013 starting...
That is, it appears the revision information seems to be intentionally
wiped from the string logged in CBMEM console there. We did recover it
from CBFS config -file:
revision 6ed0cbf6248d5b4311778d8a5d6e4fc674755f55
Regards,
Kyösti
Am Montag, den 24.03.2014, 22:36 -0700 schrieb David Hendricks:
> On Mon, Mar 24, 2014 at 9:10 PM, mrnuke <mr.nuke.me(a)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.
David, thank you for that offer.
Vladimir also hinted in #coreboot, if the hardware would be given to him
he *could* try a port (with no promises of course). He was on vacation,
so I waited to bring this up on the list. I am sure more people would
sponsor such an effort. The question is how to best do that, so people
do not get problems with taxes and so on?
A Kickstarter/something similar campaign?
If at least Alex and Vladimir participate, we’d need two to four
laptops, depending how critical a second model is to have for
development.
> Note 2: This might be a good place to start:
> https://chromium-review.googlesource.com/#/c/188275/
The other question is to decide on a laptop. Only the HP Elitebooks seem
to have a long shelf life, but these do not look like consumer products
and look more to be for companies if I am not mistaken.
http://www.heise.de/preisvergleich/hp-probook-6475b-b5u26aw-b6p75ea-a798418…http://www.heise.de/preisvergleich/hp-probook-655-g1-h5g82et-a1034671.htmlhttp://www.heise.de/preisvergleich/hp-probook-455-g1-h6p57ea-a962206.html
I had my hands on a Asus U38N-C4010H which was very well manufactured in
my opinion and a nice consumer laptop.
http://www.heise.de/preisvergleich/asus-vivobook-u38n-c4010h-90ntia212n1292…
In the IRC channel #coreboot also the Lenovo X131e was mentioned. I have
no idea what to make of that AMD E1-1200 processor.
http://www.heise.de/preisvergleich/lenovo-thinkpad-x131e-3372-1a6-a998573.h…
Thanks,
Paul
I'll try to be short.
* Usually, ARM payloands need to use SoC specific drivers to access storage
devices.
* Sometimes coreboot implements the same drivers.
Proposal:
* Share these drivers between coreboot and libpayload.
* libpayload is BSD. Have a "[ ] Enable GPL features" config option which
"unlocks" the GPL'd drivers from coreboot.
* libpayload core remains BSD.
* coreboot drivers are available to GPL users of libpayload
* Both the licensing of libpayload-core and coreboot is maintained/respected
* Makes maintenance easier
* Makes libpayload relevant in the ARM space
Alex
On Mon, Mar 24, 2014 at 10:31 PM, ron minnich <rminnich(a)gmail.com> wrote:
> 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.
>
I think the ARM Chromebooks will be excellent targets for the reasons that
you cite (few if any blobs, no ME, open EC firmware) once we get the
situation resolved w.r.t. loading a kernel in a sane and consistent manner.
IIRC even the Mali graphics drivers are becoming more open these days,
though I don't know the exact status off-hand.
Of course I'm biased in this matter ;-)
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!
>
Yeah, that's something volunteers in the community should coordinate on if
folks are really gung-ho about this. Porting to older hardware is a fun
exercise and certainly educational, but IMO that's not necessarily going to
make RYF laptops the norm any time soon.
Perhaps there are some families of laptops a few active contributors will
be able to coalesce around. Maybe Lenovo models with AMD chips use the
familiar EC firmware and would make good targets to port to over multiple
generations. It would be great to see individuals and groups like Gluglug
selling more modern, desireable laptops.
On 25.03.2014 06:34, ron minnich wrote:
>
>
>
> On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <phcoder(a)gmail.com <mailto:phcoder@gmail.com>> wrote:
>
>
> I don't see how this prevents any of my propositions for the bulk of the
> boards. The problem you describe isn't going away with your proposition.
> We still want to have a top which is supposed to work on all boards.
>
>
>
> All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10?
> All boards? Are you sure?
>
That's why I added *supposed to*. I'm aware that some boards are
probably broken and not much we can do about it.
> ron
