Chromebook HP 14 Linux/Developer Mode Issue

[Manuel Madrid]

Hello all,

If this isn't the correct or best place to ask this, I'd appreciate any and all referrals. 

I'm posting this here because I really haven't the foggiest how to go about fixing my issue. I recently installed Linux through Crouton onto my Chromebook without an issue (obviously before this I enabled Developer mode).
In addition, I downloaded and installed a variety of programs using this tutorial: http://installfest.railsbridge.org/installfest/

Just a notice, I had installed Linux and had it running for a few days before taking the plunge into the InstallFest. 

I made it nearly all the way to the end of the installation (last night), with the only hiccup being that after I got Webrick up and running, I couldn't create a "new drink". I left things at that for the evening and settled to finish the installation today. Here's where my problems begin:

I ran my chromebook and was having issues connecting to a wireless connection that I have been using for the last week or so (public school connection). I tried turning off my wifi and connecting again to no avail and then finally rebooted my chromebook to try again. I was faced with a screen saying, as expected, that my OS verification was off to which, as I have before, I pressed cntrl + d to enter developer mode. It loaded and the wifi worked, however, when I tried switching to my Linux OS (cntrl + alt + forward and then refresh) it wouldn't let me, informing me that I had to enable developer mode. 

I was worried that my Linux profile and all the time I spent installing programs to it had been erased, I rebooted my computer (esc + refresh + tap of power button). This time I was met by a screen that said something along the lines of "OS system missing or damaged insert USB". The screen didn't allow any keystrokes and, eventually, loaded into regular Chrome OS log in. I had to re enter my Google data and retrieved all my personal information (plug in photos were missing though for some reason). Still, developer mode wouldn't work. I tried the same process, again telling me that OS verification was off, I hit cntrl + d but, when it loaded, it still prompted me as if developer mode wasn't engaged.

I'd hate to have to admit that the hours I put into installing Linux and the installfest were wasted, but I'd much rather that than some serious error in my device. If my Linux is salvageable and anyone has an idea how to go about it, I would be a 1000 times in their debt.

(side note, I even tried "chromeos-firmwareupdate --mode=todev in the nondeveloper BASH" no luck.

Thank you!

[Israel Lopez]

Did your battery drain like mine did? https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-discuss/tZHXZpM47d8

It almost sounds like that is what happened.

--
--
Chromium OS discuss mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Manuel Madrid]

Hey Israel,

Come to think of it, the battery may have drained the night before. I didn't even think of it. So the next step is using another computer to get Chrome OS onto a USB? Also, is it safe to say my Linux side stuff is lost?

You've been very helpful.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-discuss+unsub...@chromium.org.

[Israel Lopez]

Hi Manuel,

Benson posted this link in that thread on how to build a "recovery USB" and describes the issue. The flags for Legacy Boot / USB Boot Were Lost I think. 

http://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices/workaround-for-battery-discharge-in-dev-mode 

If you can boot from a USB drive, you might be able to recover the linux data, but probably not the entire OS.

I'm dealing with this now with a computer lab that I delivered to Africa, its annoying, but it would be awesome if the BIOS behaved more like a traditional system. :-/

-Israel

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dis...@chromium.org.

[Mike Frysinger]

I know this has been described before, but the firmware is, by design, not behaving like a traditional bios, and most likely that isn't going to change.

that isn't to say settings should be lost on battery drain. but changes there have to be done without compromising security, and even then they most likely won't be backported to older devices.
-mike

[Greg Stark]

On Sat, Aug 30, 2014 at 11:50 PM, Mike Frysinger <vap...@chromium.org> wrote:
> that isn't to say settings should be lost on battery drain. but changes
> there have to be done without compromising security, and even then they most
> likely won't be backported to older devices.

Supposedly that work-around can reset those flags from an unsigned
boot image so I don't think there's any actual clear security
rationale for those settings. It looks like they were added to be
"more secure" without carefully thinking through what threat vector
they're actually protecting against.

However I have again lost my Linux install today. And I tried that
method. And I can't get it to work. All I get from my Pixel is "The
device you inserted does not contain Chrome OS".

Moreover, my battery never ran out. It seems there's some code path
where those flags get reset explicitly lying in wait to trap
unsuspecting users. In my case it happened when I was intentionally
trying the rescue instructions so my suspicion is that the
ESC+F3+Power recovery sequence resets them.

The idea of signed OS images is brilliant. Being able to turn it off
is brilliant (though it would be even cooler to have a general purpose
mechanism so I can upload my own signing key and continue using the
feature). But these additional flags seem to serve no particular
purpose except to get in the way.

--
greg

[Greg Stark]

On Sat, Sep 13, 2014 at 10:04 PM, Greg Stark <st...@mit.edu> wrote:
> However I have again lost my Linux install today. And I tried that
> method. And I can't get it to work. All I get from my Pixel is "The
> device you inserted does not contain Chrome OS".

Interesting. I just got it to work. I had to use a Windows machine to
generate the recovery disk, for some reason the recovery disks burned
on Linux using dd just weren't being recognized at all. And Windows
couldn't burn to a USB stick but seems to have burned an SD card fine.
Unfortunately neither gave much of a hint what went wrong. Chromeos
just said "The USB or SD card doesn't contain Chrome OS".

So now I have a rescue SD card I can use whenever my Chrome box
randomly decides to reset this flag which seems to happen quite often.
I'm mostly happy with this situation now.

I wonder if it would be possible to set up a partition table and put
this recovery image on it so that if I press C-d it boots to this
image and resets dev_boot_legacy automatically without having to carry
around the rescue SD card. Then I would basically have three keys on
startup, C-l to boot linux, C-d to reset dev_boot_linux (and of course
space to wipe my computer(!!)). I'm not sure if that would work
however, when you press C-d the boot to usb media might be an entirely
different codepath from the boot from random partition on the drive.

--
greg

[Mike Frysinger]

On Sat, Sep 13, 2014 at 4:04 PM, Greg Stark wrote:

> On Sat, Aug 30, 2014 at 11:50 PM, Mike Frysinger wrote:
> > that isn't to say settings should be lost on battery drain. but changes
> > there have to be done without compromising security, and even then they most
> > likely won't be backported to older devices.
>
> Supposedly that work-around can reset those flags from an unsigned
> boot image so I don't think there's any actual clear security
> rationale for those settings. It looks like they were added to be
> "more secure" without carefully thinking through what threat vector
> they're actually protecting against.

the extended developer mode features are not hard required for
shipping a product (like USB/SD/legacy booting). they exist because
firmware devs spend some of their "spare" time to try and do right by
our customers. but when it comes to security, it's safer to be
pessimistic and default to "no" than to inadvertently introduce a
firmware/ec exploit in the read-only portion of flash. we only have
one chance to get this right :). over time as we see a feature
progress and get a better handle on how things look, we can
investigate relaxing certain flows.

in this particular case, while the recovery image rootfs is modified,
the kernel is not. so the kernel is still properly signed and the
firmware validates it. the fact that the kernel then allows itself to
mount & execute an unsigned rootfs is because the device is in dev
mode. if you flipped the dev mode switch back, then the recovery
kernel should have rejected the modified rootfs.

disclaimer: if it still does execute unsigned code in non dev mode :),
then this isn't exactly a security issue either. once you eject the
recovery image, the firmware will require the installed kernel to be
properly signed, and that will require the rootfs to be properly
signed.

arguably, having the firmware be more restrictive than the recovery
image in terms of what it allows to boot by default is not
intentional. we probably want to file a bug on the topic to noodle
over it some more and harmonize the behavior.

> Moreover, my battery never ran out. It seems there's some code path
> where those flags get reset explicitly lying in wait to trap
> unsuspecting users. In my case it happened when I was intentionally
> trying the rescue instructions so my suspicion is that the
> ESC+F3+Power recovery sequence resets them.

if this is reproducible, then we should file a bug via
http://crbug.com/new to investigate and fix newer versions.
-mike