Re: On a Samsung ARM Chromebook, could nv-uboot easily boot to stock linux kernels, by way of ARM-GRUB?
Sorry to butt in, but this seems a little strong to me -
"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: 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."
Because you can turn off the checking and boot up pretty much
anything, and if you can boot up a second stage bootloader that's not
signed then the world is your oyster.
I'd agree these devices could be more open, but they aren't locked
down like a console or anything.
On Wed, Jan 1, 2014 at 5:09 PM, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> 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: 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.
>
> 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.
>
> 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?
>
> so.... yeah, if someone's already done custom-compiled packages then
> you are very, very lucky.
>
> l.
>
>
> --
> To UNSUBSCRIBE, email to debian-arm-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] CAPweEDyyfQRgredyzcaVWO8bRqENFq+2=Hnryua9cxpe1fuNuQ@mail.gmail.com">http://lists.debian.org/[🔎] CAPweEDyyfQRgredyzcaVWO8bRqENFq+2=Hnryua9cxpe1fuNuQ@mail.gmail.com
>
Reply to: