Re: On a Samsung ARM Chromebook, could nv-uboot easily boot to stock linux kernels, by way of ARM-GRUB?

[Subharo Bhikkhu]

Hello Luke,

On Wed, Jan 1, 2014 at 12:09 PM, Luke Kenneth Casson Leighton <address@hidden> wrote:

subharo, hi,

basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM:

I agree with David Hicks.  I think Googl (or Samsung) is slightly less evil than you're portraying them, since at least Google supplies the alternate nv-uboot bootloader whatsoever.  The "nv" here stands for "non-verified", meaning Google is providing a way to bypass the bootloader signing.  They didn't need to do that.  I think that linux geeks would probably prefer (instead of nv-uboot) that the alternate "non-verified" bootloader would be GRUB, which is far more feature-rich, and well known than nv-uboot. 

Google, are you listening?  My 2 cents: Please use GRUB in the future for your bootloader, by default, if you're too cheap to include a Debian-friendly BIOS in your hardware.  GRUB is trying to support EFI (at least on AMD64, at present), and there are efforts to bring GRUB into the ARM world.  You're reputation for "not being evil" is long gone, IMHO, but perhaps here's a way to try to earn it back.

 

once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse.  and then put the plastic back.

actually, there *might* be a cheaper way: obtain a replacement
processor, pay for the treacherous one to be removed and have the
"stock" one soldered in its place (and then blow the e-fuse which
permanently disables treacherous computing).  as this would involve
heating up the board to around 200C and these SoCs have a hell of a
lot of pins it is not without risk.

 

Your point is taken that "owning" hardware like this (by applying some reasonable, reproducible method) is very, very difficult, and is pretty much only for elite linux geeks to attempt.  Scripts like Chrubuntu may help the newbie user get off the ground with a few mere hours of tinkering, but then they'll run into a brick wall later, once it's time to re-install the OS (or they try a dist-upgrade, when virtually nobody has ever QA'ed that that will work well, as is the case for my potential Chrubuntu 13.04 -> Chrubuntu 13.10 upgrade, which I know better than to attempt).
 

but, without going down that insane route, you are along the right
kind of lines with loading a 2nd bootloader - one that can then load
an unsigned kernel.

there is potentially a simpler option: you might wish to look at the
kexec option.  this would allow you to continue to use the *existing*
kernel - unmodified - purely as a bootloader.  there is a userspace
program kicking around which allows selection of kernels (heck, you
could even try using grub in userspace).  modify /sbin/init (or other
method) to run that userspace "kernel-selector", then that userspace
kernel-selector-program will kexec the *actual* kernel that you
require, which can, of course, be anything you want.

To me, GRUB seems a cleaner approach.  It gives the valuable option of booting kernels in recovery modes, which is something that might not be available using your approach.  Your approach needs a working kernel, before you can boot other kernels.  But what if you have booting problems with that first kernel somehow?  Your approach seems vulnerable to a chicken-and-egg problem, should that first kernel somehow not boot.  GRUB has lots of available tricks for getting out of those tight jams.  Having said that, I'm not feeling up to actually trying to cleanly (and reproducibly) shoehorn GRUB in there.  Sorry everyone, for just being "all talk and no action" on this one.  I'm feeling too old and battle-scarred for that now.

Before you flame me, at least I did discover something new and useful to contribute, and it's this.  If you went the way I did (installing Chrubuntu 13.04 to the internal 16GB eMMC), and you instead want to move to Karl L's *much* cleaner and correct Debian Jesse install, you can at least boot back to ChromeOS first (which is needed *before* following Karl L.'s procedure), by adjusting the GPT partition priorities as follows.

Do this from a terminal, within Chrubuntu:

sudo cgpt add -i 2 -P 13 -S 1 /dev/mmcblk0

sudo cgpt add -i 4 -P 14 -S 1 /dev/mmcblk0
sudo reboot

This effectively took me back to ChromeOS.

 

regarding the custom-compiled packages: yep... tough.  that's how
things are in the ARM world.  i won't say "get used to it"... instead
i'll say "please *consider* getting used to it" :)  there is no BIOS:
*every* kernel is custom-compiled and hard-coded to match the
hardware... which, because there is no BIOS, and all the CPUs are
different *and* all the hardware is different.... you see how that
quickly becomes a complete nightmare?

 

Indeed.  It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where the solid state hardware lasts *even less long* than the non-solid state hardware that came before it, and this planned obsolescence was very intentionally engineered (as you explained with the e-fuses, "verified" bootloader, etc.).

so.... yeah, if someone's already done custom-compiled packages then
you are very, very lucky.

Thanks for helping me to appreciate Karl L.'s work.  I'm now on my way to following Karl L's procedure to install Debian Jesse.  So this  story has a somewhat happy ending.

Cheers,

Subharo Bhikkhu