Upgrade of crouton bricks Chromebook due to dev_boot_signed_only=1

[wchao]

I have an Acer C720 running ChromeOS 34.0.1847.118. I installed crouton on my Chromebook and it worked great. Because I wanted to use virtualization, I chose to add the disablevmx=off option to the kernel boot command line, which required that I set dev_boot_signed_only=0. All was well. Then I upgraded crouton, which set dev_boot_signed_only=1 again. When I rebooted, my Chromebook was unable to boot the active image, since it requires a kernel signed by Google.

I would like to suggest that when performing updates, crouton first check if the currently active image is signed by Google. If not, it should not set dev_boot_signed_only to 1. Otherwise people will run into the same problem as me. That should help for the future.

Does anyone know how I can either set dev_boot_signed_only=0 or boot using the previous boot image in /dev/sda2 or /dev/sda4? I believe the other boot partition has a boot image that IS signed by Google, so if I can get in, then I can run crossystem dev_boot_signed_only=0 and all should be well. It's just getting in that's the hard part. I'd prefer not to reformat the drive since I spent a couple of days getting the chroot Debian and the Windows VM under VirtualBox just so, and I'm not looking forward to repeating all that work.

[drinkcat]

crouton should not reset the flag (even if the kernel is signed: it's ok to throw a warning, but it should not reset it): we can easily fix that.

I'm not aware of a way to force booting the alternate kernel (have you tried doing a few hard resets with Power+Refresh?).

You could try booting off a USB disk with a Chromium OS image, but you probably do not have USB booting enabled (otherwise crouton would not have reset dev_boot_signed_only), so that won't help...

My guess is that you have no way of booting your system except by creating a Chrome OS recovery USB disk, which will erase all the content of the drive... (another alternative would be to open the Chromebook, take out the SSD, and connect it to another computer to recover the content, but, well, NGFF adapters are not very common...)

[dnschneid]

I'm really sorry about that. I thought the heuristics I have in place to not set the signed_only bit were sufficient, but apparently they were not. Turns out it's pretty hard to figure out if it's safe to set that bit or not.

Sounds like we need to do one (or more) of four things:

1. Figure out some foolproof way to determine whether it's safe or not. This is a pretty hard thing to do short of verifying the kernel partition using some built-in script I'm forgetting the name of. Doing the full verification should result in the correct answer, but it takes a fair bit of time. If we wanted to switch to that (instead of the heuristics), we should kick it off in parallel and update the boot flags at the end of the crouton installation process.
2. Figure out a heuristic that detects this kind of modification and add it to the arsenal. Maybe that's all that's left to be detected, but who knows.
3. Set a flag in /usr/local when we set dev_boot_signed_only the first time, and if we see it unset, don't set it again. I don't like this, since it pokes at stateful even if your prefix is on an SD card. Also sometimes people unset it for whatever reason and forget about it, even if they could be running with it enabled, which is much more secure.
4. Set dev_boot_signed_only on install, but not on update. I don't like this either, as it's inconsistent and potentially surprising.

[tedm]

I don't think Crouton should ever automatically change dev_boot_signed_only=1. Since a crouton user is already in developer mode, they should be well aware that settings like enabling usb boot and disabling OS verification are less safe than than the out of box settings of the Chromebook.

However, I realize a lot of folks use ONLY Crouton and ChromeOS and they would benefit from having these set for them. So if the text warnings during install and updates aren't enough, please consider having a flag for installs and updates for users who do not want Crouton to change these settings, as we are using our Chromebooks to test non-signed distros, or need features that won't run with the signed os setting, and usb/sd boot disabled. Thanks.

[dnschneid]

I'd argue the opposite; only those who really know what they're doing should run make_dev_ssd.sh, manually unset dev_boot_signed_only, and set dev_boot_usb while they're at it to avoid any chance of dev_boot_signed_only to be set. crouton puts out a warning when it sets dev_boot_signed_only, although it'd be more visible if it were at the end.

What features don't work with usb/sd boot enabled? If you're testing various distros, you'd be crazy to not have usb/sd boot enabled.

[tedm]

@dnschneid Perhaps I worded my last message incorrectly.

The last time I made up a bootable SD card with Arch linux on it, I needed to use these commands:

crossystem dev_boot_usb=1 dev_boot_signed_only=0

I would generally want those commands to "stick" so that anytime I wanted to boot my chromebook with Arch and the SD card, all I have to do is poweroff, insert the SD card, and press ctrl-U to boot arch from SD, though most of the time, the SD card isn't used, and I'm using Crouton and ChromeOS.

However, on occasion, I may also want to be able to powerwash and revert the system to chromebook oob non-developer mode (dev_boot_signed_only=1 and dev_boot_usb=0), if say a family member wants to borrow it for a trip and uses ChromeOS only.

[dnschneid]

That's covered by the heuristics today. If you set dev_boot_usb, crouton will never touch dev_boot_signed_only.

It also checks if rootfs can be mounted read-write, which I thought would cover the non-external-boot cases but apparently does not (sufficiently). That's the issue here. Maybe we just need an additional check if the kernel partition can be mounted read-write as well?

[tedm]

OK, then my use cases will work with the current heuristics then. Thanks.

I am not aware of all of the current possibilities with read-write of non-signed OS's internally. The last time I was looking at booting arch from internal, it required a screw or wire removal from inside the samsung arm, and I wasn't comfortable doing that mod, although the idea of running arch in the chromebook faster, and without the card hanging out was tempting. It sounds like folks now have os's or 3rd party filesystems booting and running internally without hardware mods on the ARM?

[drinkcat]

Just to confirm I understand the problem, is the following statement correct? After the switch to dev mode, dev_boot_signed_only is set to 0, and crouton wants to reset it to 1 for extra security.

• If that's not true (default is 1), I believe a better approach is never to touch the flag, and throw a warning as we do for other flags.
• If that's true, what is the likelihood that this will cause problems? After all, even with dev_boot_signed_only to 1, a nasty program running in the chroot could replace the kernel or remount the rootfs r/w, and, if it can do that, nothing prevents it from setting dev_boot_signed_only back to 0 as well.

Re kernel verification, we could use vbutil_kernel --verify, but I'm not sure what to check for in the output (key checksum?), and, as you said, we should make sure we are not missing anything else in our heuristics...

If we really want to set it back to 1, I would ask the user before doing it (with a message like "If you have no idea what I'm talking about, press Y"), and remember the choice somewhere in /usr/local or home directory. But we should still throw a warning later on, just in case the user forgot about it.

[tedm]

@drinkcat I believe your first sentence is correct. Your 2nd bullet about problems are that with dev_boot_signed_only set to 1, which the link below says persists as long as you stay in dev mode, is that you can't boot non-google signed OS's like chrubuntu, or arch, externally or internally (?) until you reset dev_boot_signed_only back from 1 to 0.

In fact you can't even really check the true state of this bit except before boot. Some of the things below are old, for example, netflix runs in dev mode, so these docs below could be old or device dependent:

But if the document is correct in that once dev_boot_signed is set to 1 by the user after entering dev mode, or by letting Crouton do it, then crouton updates shouldn't need to reset it, as it should already be set, unless someone explicitly reset it to 0 for a purpose. Crouton could warn users though, in case they forgot and want the security, so a warning is fine during updates, and as long as an alternate boot is not enabled, perhaps Crouton always setting signed boot to 1 is OK on install, and checking/notifying during updates.

https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot

https://groups.google.com/a/chromium.org/forum/#!msg/chromium-os-discuss/nMZCsQbq_84/K0Uz9iH77_cJ

[dnschneid]

The current heuristics have been in place for more than a year. If you haven't noticed it, then it's because they cover 99% of cases. There have been two bugs filed where the heuristics failed; the first was fixed a year ago with the read-write heuristic, the second is this bug here.

I'd rather get the heuristics right or do a full validation (I believe there's a script that wraps vbutil_kernel --verify and compares the output against known keys) than add user prompts for scary things and store responses in random parts of stateful.

[wchao]

I have to say I totally agree with David that it's a lot better for the heuristics to get it right than to emit a scary warning trusting that the user will get it right. I think if you had 50 GB of data wiped out due to setting dev_boot_signed_only=1, you would probably agree :-. (I installed a 128 GB SSD).

[tedm]

@wchao I'm sorry about your data loss. I've had a few myself, and currently put precious data in ~/Downloads accessible from ChromeOS in case my chroot gets corrupted in any way.

I initially liked your suggestion in your 2nd paragraph of your original post:

"I would like to suggest that when performing updates, crouton first check if the currently active image is signed by Google. If not, it should not set dev_boot_signed_only to 1. Otherwise people will run into the same problem as me. That should help for the future."

but then David explained that the current heuristics would not set that if the user has already set dev_boot_usb on (my use case for not wanting crouton to set to 1)

so if David's idea above of doing a 2nd check:

"Maybe we just need an additional check if the kernel partition can be mounted read-write as well?"

would work to prevent the situation you had, and all current known cases of setting dev_boot_signed_only to 1 then that seems like a good approach.

Can you confirm that David's idea of the "additional check if the kernel partition can be mounted rread-write" would prevent the issue you just experienced?

[wchao]

It's not a huge loss (mostly just time). I can recreate all the data (just takes some time sitting there waiting for the machine to install software). Regarding your questions about when to set dev_boot_signed_only to 1, I would say there are several motivations for caring about that flag. First, there is the motivation of added security, which I think we would all agree is good, except when it conflicts with other motivations. A second motivation (in this case, in the opposing direction) is not wanting a bricked machine.

I am not sure what relation the kernel partition being read-write capable has to being able to boot the machine (i.e. not having a bricked machine). Suppose the kernel partition can be mounted read-write. Does that imply that the Chromebook will boot a partition that is not signed by Google? If a read-write capable partition always implies that Chromebook will boot that partition, then I would say that is a good heuristic that will ensure a machine never gets bricked (at least from setting dev_boot_signed_only=1).

I was not aware that crouton will avoid changing dev_boot_signed_only when it sees dev_boot_usb. Now that I know that, I am definitely going to set dev_boot_usb to 1 when I reformat and reinstall! I also learned that I can set the boot priority using cgpt to try different partitions in order (http://dev.chromium.org/chromium-os/developer-information-for-chrome-os-devices/cr-48-chrome-notebook-developer-information/how-to-boot-ubuntu-on-a-cr-48#TOC-Set-boot-priority). I am going to do some testing with that to see if I can make my configuration more resilient in the future (in case I run into a similar situation).

For other unsuspecting people in the future, it would be good to have a foolproof (or as foolproof as practically possible) heuristic for determining when it is safe to set dev_boot_signed_only=1. In my mind, that is checking whether the boot image is signed by Google or not. Is there some way to verify the signature of the boot image using vbutil_kernel or some other tool, and compare to Google's public key? If you could do that, then you could avoid setting dev_boot_signed_only when you know that the next reboot will brick the machine.

[wchao]

I managed to recover the data. I had another Chromebook and realized that if I took the SSD from the other Chromebook, I would be able to boot. Then I set dev_boot_signed_only=0, and installed the original SSD. Problem solved.

[tedm]

@wchao that is genius! I wonder why I did not think of that (other than my samsung arm has a soldered in emmc I think).

I'm still not sure of the best overall solution here. I know that I personally would want dev_boot_signed_only=0 to stay that way if I set it that way for a purpose, but I can also see that for many Crouton users using the standard unmodified targets and default kernel boot options, that it offers some protection by setting back to 1.

[drinkcat]

@wchao: Good job getting your data back ,-)

I came up with the following script: https://gist.github.com/drinkcat/10843992 , making use of dev_debug_vboot. I'll integrate it in the installer later on.

The logic goes like this:

• KERN-A and KERN-B must be signed (as shown by @wchao, having only one good kernel is not enough to make sure the machine can boot)
• KERN-C is allowed not to be signed (for Chrubuntu, and the default case where KERN-C is an empty partition). We have not heard of any problems with Chrubuntu users, but is that really safe?

I only tested signed Chromebooks at this stage (QEMU is a bit irrelevant as there is no flag to start with), @wchao maybe you can help to confirm this works.

@DennisLfromGA, since you have Chrubuntu installed, can you check what is the output is your case?

Finally, the test takes about 15 seconds (reading the firmware is slow), should we consider caching the result somewhere in /tmp? (only if the result is negative, that is, if verified boot must not be enabled)

[wchao]

@drinkcat: I tested your testsig.sh and it works on my system. Here is what I get:

Saving verbose log as /tmp/debug_vboot_2sT8b92S6/noisy.log
Extracting BIOS components...
Pulling root and recovery keys from GBB...
Verify firmware A with root key: OK
TPM=0x00010002, this=0x00010002
Verify firmware B with root key: OK
TPM=0x00010002, this=0x00010002
Examining kernels...
Kernel /dev/sda2: OK
Verify /dev/sda2 with kern_subkey_A.vbpubk: FAILED
Verify /dev/sda2 with kern_subkey_B.vbpubk: FAILED
Verify /dev/sda2 with recoverykey.vbpubk: FAILED
Kernel /dev/sda4: OK
Verify /dev/sda4 with kern_subkey_A.vbpubk: FAILED
Verify /dev/sda4 with kern_subkey_B.vbpubk: FAILED
Verify /dev/sda4 with recoverykey.vbpubk: FAILED
Kernel /dev/sda6: FAILED
Checking output:
Either Kernel A or Kernel B is not verified.
RESULT: signed_boot must be kept disabled.

It doesn't take 15 seconds on my Acer C720. It takes about 5 seconds.

[wchao]

@drinkcat: I also tested when one of the kernel partitions is signed, and it also seems to work:

Saving verbose log as /tmp/debug_vboot_RnwdCU0yH/noisy.log
Extracting BIOS components...
Pulling root and recovery keys from GBB...
Verify firmware A with root key: OK
TPM=0x00010002, this=0x00010002
Verify firmware B with root key: OK
TPM=0x00010002, this=0x00010002
Examining kernels...
Kernel /dev/sda2: OK
Verify /dev/sda2 with kern_subkey_A.vbpubk: FAILED
Verify /dev/sda2 with kern_subkey_B.vbpubk: FAILED
Verify /dev/sda2 with recoverykey.vbpubk: FAILED
Kernel /dev/sda4: OK
Verify /dev/sda4 with kern_subkey_A.vbpubk: OK
TPM=0x00020001 this=0x00020001
Verify /dev/sda4 with kern_subkey_B.vbpubk: OK
TPM=0x00020001 this=0x00020001
Verify /dev/sda4 with recoverykey.vbpubk: FAILED
Kernel /dev/sda6: FAILED
Checking output:
Either Kernel A or Kernel B is not verified.
RESULT: signed_boot must be kept disabled.

What do you think about the following heuristic? If all kernels are signed, then it's safe to set dev_boot_signed_only=1. If all kernels are NOT signed, set dev_boot_signed_only=0. If some kernels are signed and some kernels are NOT signed, then display a warning along with an explanation to the user of what might happen, then give the user the choice (which should default to dev_boot_signed_only=0). In cases where some kernels are signed and some are not, it might work most of the time to default dev_boot_signed_only based on whether the highest priority kernel partition is signed or not, but still would be good to display the warning and get user input because there's no guarantee that the highest priority kernel partition will be able to boot OK.

[drinkcat]

@wchao : cool, thanks for trying it out. It does take 15 secs on my C720 (and about the same on my Samsung ARM), weird...

I'd say the logic should be:

• if dev_boot_signed_only=0 and all other cases are false (rootfs is ro, no usb, no legacy):
  • KERN-A and KERN-B signed => set dev_boot_signed_only=1
  • Otherwise (either is not signed), keep dev_boot_signed_only=0, and throw a warning with delay (just like we do with USB/legacy booting). I'm pretty sure this case will never happen if the user does not manually override the kernel, so I don't think adding extra logic to recognize the active boot partition is a good idea (more error prone).

As @dnschneid mentionned, we should also make sure that these messages gets displayed again in the TIPS at the end of the install process.

[dnschneid]

That sounds good, although I would get rid of the RW rootfs check since it's a bunch of code that only avoids the full verification check in relatively few cases.

I think the way to go about this is to kick off the verification in parallel at the point where we do the crossystem edits now, then check the result and apply the edits after bootstrap/extraction but before prepare.sh. We can put a small status output when setting the flag, then output the warning message as part of the trap handler so that it outputs at the very end, after prepare.sh has run, regardless of whether prepare.sh suceeded or not.

That has the following benefits:

1. Not increasing the install time for the vast majority of cases (since it'll happen in parallel with bootstrapping the first time around and won't happen at all for subsequent updates as long as the flag remains set)
2. Applying the flags before we enter the chroot for the first time
3. Ensuring the user knows this has been set (with informative but not scary messaging), especially if prepare.sh fails
4. Gets rid of the warning delays related to this

[drinkcat]

That sounds good, although I would get rid of the RW rootfs check since it's a bunch of code that only avoids the full verification check in relatively few cases.

Indeed. I only realised now that remounting the rootfs RW requires a kernel command line modification, so it's exactly the same scenario: the kernel(s) will not verify.

Now, I like the background idea, but I'm not sure if it's worth it, given how "interesting" multi-tasking can get in shell:

• For the vast majority of users, the check will only need to happen once (during the first ever install after switching to dev move). Then dev_boot_signed_only=1 and no further check is required. I don't think we want to add an extra layer of complexity to save 15 seconds, once.
• For power users, who need to keep dev_boot_signed_only=0, doing the test in parallel with bootstrap will only help during initial chroot creation. In that case, we would be better off running it in parallel with the whole process... However, I still think it is better to run the test once per reboot, and cache the result somewhere in /tmp: it is safe to cache the decision to keep dev_boot_signed_only=0 (even if the kernel gets replaced by a signed version, it will boot fine with the flag set to 0).

And I agree with points 3 and 4.

[dnschneid]

Since we can test the exit code via wait, it should be trivial to parallelize. I would rather avoid 15 seconds of nothing moving as a new user's first impression, even if it's only a drop in the bucket of the install time.

Caching the result for the few people who do strange configurations and repeatedly install/update chroots per boot is even less reasonable :)

[Snowflake6]

FYI, to avoid the data loss issue (maybe), as you likely have a Google account with a google drive, Insync runs very well under crouton. At least, under crouton/Xubuntu which i'm running on my C720P. My data is backed up to my google drive, and synced to three other computers at the same time (two linux boxes also running Insync, and one Windows box running Win7 and Google's drive app).

[DennisLfromGA]

@drinkcat, et all,

Sorry guys, I've been away for a couple of weeks and just got back late yesterday.

System:

Google Chrome 35.0.1916.27 (Official Build 262261) beta Platform 5712.14.0 (Official Build) beta-channel parrot

First of all, I have removed rootfs verification on my system so I can run some custom init scripts and such so this may the sully the results of the script.

My dev_boot flags are:

sudo crossystem 2>&1|grep dev_boot
dev_boot_usb           = 1                              # Enable developer mode boot from USB/SD (writable)
dev_boot_legacy        = 0                              # Enable developer mode boot Legacy OSes (writable)
dev_boot_signed_only   = 0                              # Enable developer mode boot only from official kernels (writable)

I ran the script and got this output:

sudo sh -e ~/Downloads/testsig.sh
Saving verbose log as /tmp/debug_vboot_kOhq5cQJT/noisy.log
Extracting BIOS components...
Pulling root and recovery keys from GBB...
Verify firmware A with root key: OK
  TPM=0x00010003, this=0x00010003
Verify firmware B with root key: OK
  TPM=0x00010003, this=0x00010003
Examining kernels...
Kernel /dev/sda2: OK
  Verify /dev/sda2 with kern_subkey_A.vbpubk: FAILED
  Verify /dev/sda2 with kern_subkey_B.vbpubk: FAILED
  Verify /dev/sda2 with recoverykey.vbpubk: FAILED
Kernel /dev/sda4: OK
  Verify /dev/sda4 with kern_subkey_A.vbpubk: FAILED
  Verify /dev/sda4 with kern_subkey_B.vbpubk: FAILED
  Verify /dev/sda4 with recoverykey.vbpubk: FAILED
Kernel /dev/sda6: OK
  Verify /dev/sda6 with kern_subkey_A.vbpubk: FAILED
  Verify /dev/sda6 with kern_subkey_B.vbpubk: FAILED
  Verify /dev/sda6 with recoverykey.vbpubk: FAILED
Checking output:
Either Kernel A or Kernel B is not verified.
RESULT: signed_boot must be kept disabled.

Hope this helps in any way.
Please let me know if I can do any other tests.

-DennisL

[drinkcat]

@DennisLfromGA : Thanks, that confirms what we thought. I still need to think a bit more about the heuristic of KERN-C, since some of the instructions online recommend switching to Chrubuntu using sudo cgpt add -i 6 -P 5 -S 1 /dev/sda, which will lead to issues if dev_boot_signed_only=1.

@dnschneid : Alright, I guess you convinced me ,-)

[DennisLfromGA]

Please bear with me - noob question(s):

• I know setting this flag is for 'security' purposes but just how important or necessary is it?
• Does it affect crouton chroots?
• Would it be fitting to check for and implement it only when more security is requested, like with the -e encryption option?

Curious,
-Dennis:

[rrolsbe]

wchao commented on Apr 16, 2014

I managed to recover the data. I had another Chromebook and realized that if I took the SSD from the other Chromebook, I would be able to boot. Then I set dev_boot_signed_only=0, and installed the original SSD. Problem solved.

I am looking for some clarification on exactly what wchao did and why it worked. I assume the drive from the other Chromebook must have also been in Developer Mode (or the Developer Mode status is stored in the r/w firmware) and had the kernel boot bits stored on the drive were signed by Google, else the dev_boot_signed_only=0 command could not have been executed? Also, The dev_boot_signed_only status must be stored in the r/w firmware area of Chromebooks, and NOT anywhere on the hard drive?

Thanks Much In Advance for any clarification!

Regards, Ron

PS - I had to perform a Recovery from USB after performing a crouton update. After the update and execution of the "sudo startxfce" command, it promptly crashed and rebooted thereafter. The dev_boot_signed_only must of been set to 1 by the update.

[wchao]

The other Chromebook was in Developer mode. Anecdotally, I seem to recall that in the past few months, crouton seems to again set dev_boot_signed_only=1. It didn't brick my Chromebook because I was careful to check for it after my previous near-trauma, but I'm sure some people are caught up by it. I haven't played with it much recently, so I don't know if it's still doing that as of the last few weeks.

[drinkcat]

@rrolsbe : Sorry about that... There is a fix in #785, but it has not been merged yet: we had so few reports that we deviced to leave it aside. We will revisit it at some point...

In the mean time, unless you have strong security concerns, I'd suggest enabling USB booting (crossystem dev_boot_usb=1). That'll prevent crouton from flipping dev_boot_signed_only, and provide you with another way to recover your data (booting an image from USB).

[rrolsbe]

@drinkcat

Thanks for the reply! Since I own the two C710 Chromebooks, (the ones without the Seabios payload, thus not allowing traditional Legacy OS USB booting) what can I boot via USB to access the internal hard/flash drive content? Informational link would be greatly appreciated.

Thanks Again!!
Regards, Ron

I think the link below might of worked on the original C710 to allow booting from USB without changing the factory Coreboot firmware. I tried to install this onto three different USB sticks and got the same errors all three times.

1st error - chronos does NOT have the parted GPT partition manager binary.
2nd error - Multiple errors input/output to pipe

Has anyone on this forum EVER gotten this script to properly install a bootable version of ChrUbuntu on a USB stick? If so, did it boot on the C710 WITHOUT changing the factory delivered firmware?

http://chromeos-cr48.blogspot.com/2012/12/so-you-want-chrubuntu-on-external-drive.html

[DennisLfromGA]

If you have or can build ChrUbuntu on an external usb stick and
'dev_boot_usb' is set to 1, then you can boot it via Ctrl-U at startup and
then get to your hard drive I believe.

On Wed, Jan 14, 2015 at 3:46 PM, rrolsbe [email protected] wrote:

@drinkcat https://github.com/drinkcat

Thanks for the reply! Since I own the two C710 Chromebooks, (the ones
without the Seabios payload, thus not allowing traditional Legacy OS USB
booting) what can I boot via USB to access the internal hard/flash drive
content? Informational link would be greatly appreciated.

Thanks Again!!
Regards, Ron

—
Reply to this email directly or view it on GitHub
#765 (comment).

DennyL@GMail

[dnschneid]

I noticed an interesting tidbit in the verified dev mode wiki page:

Or, from the shell, run crossystem without arguments as root. You can also run crossystem kernkey_vfy. If sig is returned, the kernel is a Google signed kernel. Any other kernel partition returns hash, so you shouldn't see that value immediately following a verfied boot.

To those potentially affected by this bug (you know who you are, and @divx118 for good measure): could you run echo crossystem kernkey_vfy`` from the crosh shell and confirm that it returns hash?

[dnschneid]

Actually, the output of echo crossystem mainfw_type`` would also be useful.

[wchao]

I am running Chrome OS 42.0.2311.87 (64 bit) with a patched kernel partition (to add disablevmx=off lsm.module_locking=0 to the kernel command line). I get the following crossystem values:

crossystem kernkey_vfy: hash
crossystem mainfw_type: developer

[dnschneid]

Sweet. One more thing: next time you (or anyone) get an update such that you have to re-patch your kernel, could you run both commands 3 times: before patching it, after patching it, and after rebooting?

[wchao]

Sure, happy to. I'm using the latest Chrome OS, so I don't know when the next time will be, but I would guess in 1 - 2 months it's likely.

[dnschneid]

If enough people say kernkey_vfy reflects reality, I might commit the check but keep this bug open until people can confirm that it changes immediately after kernel patch (i.e., not after next boot-up). I'm not sure it does, so it may just be a nice extra safety measure.

If it DOES immediately change, then it may also be worth it to add checks to crouton enter_chroot to see if the status changed, and then alert/disable verified boot to prevent people from nuking themselves even outside the context of an install or update.

[divx118]

@dnschneid If there is an update pending, the next reboot will boot another kernel. My script detects the on a reboot booted kernel and patches that. If I patch a kernel the crossystem flags will not change immediately, because the patched kernel will only be active after a reboot. This could be tricky, I need to think about it.

[dnschneid]

OK, it may be worth doing to avoid breaking an already-modified install, but it can't be used to save people about to nuke themselves.

[divx118]

I would rather prefer something like @drinkcat proposed in #785 to be really sure all kernels are signed correctly before enabling the flag. We now also have the waiting time when the flag is disabled. On my HP chromebook 14 the test takes about 5-6 seconds.
Sadly there doesn't seem to be a faster way to check the kernels.
Checking just crossystem kernkey_vfy and crossystem mainfw_type will still require that I set crossystem dev_boot_usb=1 dev_boot_legacy=1 in my script to be sure they don't get a non bootable system.

That said keeping crossystem dev_boot_usb=1 dev_boot_legacy=1 to prevent enabling dev_boot_signed_only is fine by me.

[wchao]

OK, I had the opportunity to perform an update. I ran the update, then rebooted. Then, before I patched, I ran:

echo crossystem kernkey_vfy
sig

echo crossystem mainfw_type
developer

After patching, I ran:

echo crossystem kernkey_vfy
sig

echo crossystem mainfw_type
developer

After reboot, I ran:

echo crossystem kernkey_vfy
sig

echo crossystem mainfw_type
developer

[dnschneid]

...oh well.

[9291Sam]

Over 2 years later I just had this exact issue so it seems it is still not fixed

[DennisLfromGA]

@9291Sam,

crouton's current logic is to set 'dev_boot_signed_only=1' only when 'dev_boot_usb' and/or 'dev_boot_legacy' are not set / off.

I have my options configured to boot both usb & legacy so crouton leaves the 'dev_boot_signed_only' bit unset, see below:

dev_boot_usb          = 1     # Enable developer mode boot from USB/SD (writable)
dev_boot_legacy       = 1     # Enable developer mode boot Legacy OSes (writable)
dev_boot_signed_only  = 0     # Enable developer mode boot only from official kernels (writable)

Hope this helps,
-DennisL

[tedm]

@DennisLfromGA a few weeks ago, there was a known issue where certain older Toshiba Chromebook 2's lost their video on all channels except stable. So I reverted to stable to get video back, and re-installed crouton, but the command for targets did not work:

sh ~/Downloads/crouton -t list

I was fine installing cli-extra, but that should get fixed.

[DennisLfromGA]

@tedm,

It still works for me with or without sudo

chronos@localhost ~ $ sh ~/Downloads/crouton -t list
Available targets:
audio
        Support audio playback via Chromium OS's audio system.
        Requires: core
chrome
        Google Chrome browser, stable channel.
        Requires: x11
chrome-beta
        Google Chrome browser, beta channel.
        Requires: x11
chrome-dev
        Google Chrome browser, dev channel.
        Requires: x11
chromium
        Chromium browser. Uses the distro's version, which may be old.
        Requires: x11
cli-extra
        Basic CLI tools such as ssh.
        Requires: core
core
        Performs core system configuration. Most users would want this.
e17
        Installs the enlightenment desktop environment. (Approx. 50MB)
        Requires: gtk-extra
extension
        Clipboard synchronization and URL handling with Chromium OS.
        Requires: x11
gnome
        Installs the GNOME desktop environment. (Approx. 400MB)
        Requires: gtk-extra
gnome-desktop
        Installs GNOME along with common applications. (Approx. 1100MB)
        Requires: gnome
gtk-extra
        GTK-based tools including gdebi, gksu, and a simple browser.
        Requires: x11
kde
        Installs a minimal KDE desktop environment. (Approx. 600MB)
        Requires: x11
kde-desktop
        Installs KDE along with common applications. (Approx. 1000MB)
        Requires: kde
keyboard
        Adds support for Chromebook keyboard special keys.
        Requires: x11
lxde
        Installs the LXDE desktop environment. (Approx. 200MB)
        Requires: gtk-extra
lxde-desktop
        Installs LXDE along with common applications. (Approx. 800MB)
        Requires: lxde
touch
        Touchscreen and limited generic gesture support.
        Requires: x11
unity
        Installs the Unity desktop environment. (Approx. 700MB)
        Requires: gtk-extra
unity-desktop
        Installs Unity along with common applications. (Approx. 1100MB)
        Requires: unity
x11
        X11 via autodetected backend. Does not install any desktop environment.
xbmc
        Installs the XBMC media player. (Approx. 140MB)
        Requires: x11
xfce
        Installs the Xfce desktop environment. (Approx. 250MB)
        Requires: gtk-extra
xfce-desktop
        Installs Xfce along with common applications. (Approx. 1200MB)
        Requires: xfce
xiwi
        X.org X11 backend running unaccelerated in a Chromium OS window.
        Requires: audio extension
xorg
        X.Org X11 backend. Enables GPU acceleration on supported platforms.
        Requires: audio
chronos@localhost ~ $ 

Hope this helps,
-DennisL

P.S. But if it is broken it's probably in the 'pie' category so go for it!

[tedm]

Thanks, it works, I forgot the "sh"! A suggestion would be to make crouton executable (600 or 666) and not need the sh ?

[DennisLfromGA]

@tedm,

The stateful_partition where your ~/Downloads folder resides is not mounted executable by default so making 'crouton' executable would not help, if I understand it correctly.

I re-mount it in my .bashrc script though to get past some of these limitations,

sudo mount -i -o remount,exec /home/chronos/user

Hope this helps,
-DennisL

[tedm]

@DennisLfromGA Thanks! I'll test it when I'm home. I'm pretty sure I've chmodded scripts and they've executed in ~/Downloads, and I don't recall having changed the mount flags.

These days, I'm hesitant to make many changes, since I seem to have to powerwash often. My first gen Toshiba Chromebook 2 is getting old, it still plays netflix fine, browses web, and runs crouton, but I don't think it's ever getting the ability to run android apps.

[tedm]

I have been playing with Windows bash dev edition lately, and it needs crouton badly. Perhaps the contributors should sell it to MS for $100 Billion and evenly split the proceeds ?? ;)

[9291Sam]

That work nicely