The pretender: Fooling 3dmark SkyDiver to test your card

This is a quick post about a funny discovery I made when testing a GTX 460 I received second-hand.  I also received a GTX 550 knowing that it needed a GPU fan replaced, but, in a PC built from the usual modular pieces, I put in both cards just to see if the drivers would squawk about the SLI cable I affixed between them.  It did not, but it neither activated SLI.  I ran the Sky Diver benchmark and the GTX 460 completed.  Power off. I slapped on a fan to the GTX 550 which required removal of the GTX 460 due to the unsightly tape-fastened fan and it benched slower than the GTX 460. Power off. Swapped in GTX 460 in place of the GTX 550, and launched the benchmark.  But the benchmark stated I needed a capable video card.  It reported the GTX 460 as the video card installed in the system.  Power off.  Removed the ad-hoc fan from the GTX 550 and installed it in the slot neighboring the GTX 460.  Power on with both cards. Run benchmark.

My takeaway: you stand a chance of benching other DirectX 12 cards if 3dmark's Sky Diver detects you have at least one card capable of running the benchmark.  

This does make me wonder how awful a GT 630 performs on Sky Diver. The passmark video score for a GTX 460 is around 2,600 and the GT 630 - later generation but really tiny - was below 900.

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.

Polishing some Chrome

This is a short recap on my lack of progress over the last few months in making stock Chrome a solid platform for compatible hardware. I halted work on it when I found myself unable capture the kernel that most Chrome builds deploy to the KERN-A or KERN-B partition after successfully updating the ROOT-A or ROOT-B partition. 

By accident, I stumbled on to the very tool I needed in a bit of code for SuperSU.  That tool is futility.  The command line syntax of futility is self-explanatory.  After ChromeOS reports that you are up to date, use futility to extract the vmlinuz. The next dialog requires you have cros_debug passed to the kernel at boot and that a shell (CTRL-ALT-T) grants you root. UEFI boot is assumed in this example.  The EFI partition is normally partition #12 (/dev/sda12) and for my example I have mounted it under /tmp/sda12.

futility vbutil_kernel --get-vmlinuz /dev/sda4 --vmlinuz-out /tmp/sda12/syslinux/vmlinuz.B

The futility binary can also yank out the command line for the kernel, albeit having unresolved variables, for the kernel.  With a little comparison to existing entries in the grub configuration, it seems pretty straight forward that by fetching the PARTUUID for the newly updated partition and combining that with the remainder of the verity syntax, verity can be enabled.

In the small ground made moments before writing this up, I cut a corner by specifying root=/dev/sda5, but still cheered loudly when Chrome booted and reflected the upgrade from 68 to 76. 

Despite the small victory and the ease it would seem there is in automating updates with less than 10 commands, it is unlikely I will contribute any future updates on this blog.

While searching for answers to some of my own Chrome on PC laptops, I discovered that alternatives are bountiful. With several alternative sources for a Chrome hybrid installation available, FydeOS, AtB, Chromefy, any other write-up should be provided only because it has something the others lack and something and audience connects with. The alternative offerings keep improving and simplifying the update process, which in essence achieves what I finally scored today with futility, even if it does not have a parallel to my desire to preserve factory image integrity.

Furthermore, now that TPM's have become a standard part of Chromebooks, I suspect my fascination with making an uber Chromebook from an i3 or higher Windows or Linux laptop will fade, simply due to the challenge and implication of neutering kernel-based TPM security.

As a reminder, my objective was to provide a deployment method using only stock Chrome image, with Play Store support where factory offered, and result in a system successfully applies updates.  Now that this is complete, I am moving on.