Good eve-ning

In my last post,  I stated that I was all done installing Chrome OS on ordinary PC laptops.  For the next month, I have changed my mind. The same evening as writing this post, I gave one last visit to my Chrome installations, and accidentally discovered a fix to a sign-in problem I had with Eve on my devices.  Almost all of my devices on which I can sandbox Chrome OS are absent a TPM 2.0 module, which I believed was the reason why I could never complete sign-in on a fresh install.

The discovery happened while upgrading an installation of Glimmer.  Glimmer successfully updated from 68 to 76. By grabbing the PARTUUID and a little magic with sed, verity booted with vmlinuz extracted from /dev/sda4.  Skip over the next point. I included it only to jog my own memory.

• The actual image resided on an SD-CARD on which I had installed Glimmer as a way to squeeze some extra life out of a ASUS Chromebook with a crippled eMMC.  Although updates would attempt to install, it reported that no updates were available solely because on the ThinkPad Yoga 11e (20de) the internal disk drive didn't have /dev/sda4 and higher.  Apparently a check is made before downloading, and part of the check validates there's a partition to accept the update.

After the update, I had a new message stating that this was the last release of Chrome for my device.  It also meant that no further updates were allowed. That triggered my interest to follow in the footsteps of Project Croissant and see if Eve would work as far back as a BayTrail CPU.

With this current update of Glimmer, I had no idea where the system recorded the flag that no further updates were allowed.  Even by advertising it as an Eve, no new updates were available.  I rolled back to 68, which invalidated my stateful partition - not exactly unexpected - but after getting to a console,  I redeployed Eve to a resized /dev/sda5.  This redeploy involved taking advantage of /dev/zram0 to hold the expanded contents of the Eve .zip  and losetup -P to expose the partitions.  Then a dd of /dev/loop1p3 to /dev/sda5, capturing /dev/loop1p2's, /dev/loop1p4's vmlinuz and kernel configs, and finally the /dev/loop1p12 EFI partition contents.

Eve booted with vmlinuz.A from its EFI partition, but didn't with the /dev/loop1p2 derived vmlinuz.  I realized that Eve has two different kernels in the dl-edge recovery image. The /dev/loop1p2 derived image was larger than vmlinuz.A.  /dev/loop1p2 also has cros_recovery in the kernel config.  This suggested I ought to use kernel derived from /dev/loop1p4.  And, so, I discovered that the /dev/loop1p4 derived kernel worked with verity.

I expected wireless, bluetooth and sound to be asbent.  eve-release/R76-12239.92.0 doesn't come with firmware for the Intel 7260-AC, and it doesn't load support for the sound chipset in my device, but modprobe snd-hda-intel solves it.  I learned that with verity turned on, I must pass lsm.module_locking=0 at boot.  I then used the same technique I previously wrote up for my Dell Latitude 5175 to get wireless working on the ThinkPad Yoga 11e.  Surprisingly, I was not presented with a fresh Chromebook setup dialog; however, the installation continued to report that it was the last update for my system.

This was good and bad news. The good news is that I was able to get Eve working with my BayTrail. That bad news is that the stateful partition would have to be powerwashed, and I would almost certainly be unable to complete initial setup sign-in.

The normal symptom from a newer ChromeOS on a BayTrail/Haswell has been a BIOS boot loop, the screen fades to white, or I can't complete initial setup sign-in.

To rid myself of the update flag, I would have to powerwash.  After powerwashing, instead of the Chrome splash, I experienced a boot loop in to the all to familiar recovery dialog.  Instead of counting up to 5 minutes, it rapidly rebooted barely giving time black & white to see the recovery screen.

I booted a live CD and formatted the stateful partition of the internal disk to ext4 with a volume name of STATE.  I rebooted back to Eve, and sign-in failed, as expected.  Sign-in would get just beyond MFA, and then spin for about 5 minutes before reporting that sign-in failed.

I repeated the sign-in process and the system became unresponsive. I then used CTRL-ALT-F2 and signed in to the text console as root.  There was a delay of several seconds before the text console came active. I ran the command top, and observed that flashrom was using a fair amount of CPU.  I killed off flashrom, and a new flashroom process appeared to have spawned in its place.  I killed it again, and top finally indicated the CPU was nearly idle.  I returned to the Chrome interface and I was now prompted with settings for my account.

This can many any number of things, but here are two possibilities:

1. Eve now ignores TPM as a requirement and retry signing in will now complete first-time setup of a Chromebook.
2. Eve tries to flash updates before permitting setup (sign in) of a new Eve Chromebook, and if that process times out, so does signing in.  Killing off the flash updates might be accelerating the sign in process.
3. Dumb luck and timing. EDIT: 09-22-2019. I powered up the laptop and couldn't get signed in. I this happened on the 09-12-2019, but happened again. Although I had previously formatted STATE ext4, I found hints of legacy glimmer configuration under /mnt/stateful_partition/encrypted. Eve somehow snagged an update_engine config directive files and what looks like cache content, to which end removing them resolved the no more updates available issue, but after a restart, I could not get signed in.  Perhaps a previous accidental partial boot to glimmer corrupted STATE, or perhaps the purge of the glimmer containing data did me in.  I repeated the wipe of STATE.  And just like the issue on 09-12, I was unable to get signed in.  For what it is worth, I proved that even when Eve is allowing me t sign in, I can't get signed in when offline.  If I close the lid on an active session, I can resume.  If I power off, to get logged in next time, I have to be online.  Therefore, removing tpm_managerd isn't helping. Neither was killing flashrom on setup, other than, flashrom did appear to be a long running process during initial eve setup. Takeaway: It looks like that in addition to putting a layer over /lib/firmware, I'll have to put a layer over the place where swtpm should be deployed.   To keep with my desire to only use code from trusted sources, I will need to automated building my own swtpm.  I see Crossiant distributes the source code in the same spot as the .tar archive, yet the paranoid side of me thinks that binaries which process and contain sensitive user credentials are a good target for bad actors.  Building this myself is not the result I would like to have with eve; however, I feel it is better than building my own ROOT-A -B or -C, with or with other's projects, and then have to learn how to lock it back up with verity.  Or worse, disable verity.

Here's a strange behavior on my ThinkPad Yoga 11e running Eve:

• Pressing SPACE-n-m produces a beep. EDIT: 09-16-2019 this actually appears to be a key-jamming indicator.  B-N-M also does it, but J-K-L does not.  H-J-K-L also beeps.