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
> > * 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
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!