CPU emulation and patches
Google's binaries use CPU instructions that most laptops do not have. gbOS86 handles that in two layers.
The problem
The Googlebook OS build uses newer instruction-set extensions: GFNI, AVX-VNNI, SHA-NI, 256-bit VAES and VPCLMULQDQ, and AVX-IFMA. A CPU without them raises an invalid opcode (#UD) fault when it meets one, and the process would crash. Newer CPUs run them natively; Intel laptops from about 2015 to 2021 do not.
Layer 1: kernel emulation
The kernel's #UD handler decodes the faulting instruction, executes the equivalent on the saved vector state, and resumes the program. It is correct, covered by about 13,000 known-answer tests, and slow: roughly a microsecond per emulated instruction. An emulator self-test runs in QEMU on every kernel build and must report 16 of 16 passing.
Layer 2: binary patches to the hottest code
Profiling the boot showed two functions causing most of the traps, so they are replaced with versions that avoid the missing instructions:
| Library | Change | Share of traps removed |
|---|---|---|
libz.so (system, vendor) | adler32_z always takes its scalar path. | about half of all emulation |
libcrypto.so (system, vendor, Conscrypt APEX) | SHA-NI SHA-256 replaced by scalar SHA-256. | about half of what was left, and Play Store installs stop crawling |
Binding them early
The patched files are bind-mounted over the originals. early_patch.sh does this before stage0's first partition-mapping call, because every mapping process loads libcrypto, whose start-up integrity check runs SHA-256 through SHA-NI: about 3.7 million emulated instructions and roughly 2 seconds of boot. hook.sh repeats the binds later as a fail-safe and logs already patched if the early pass got there first.
Hash pinning
A patch is only applied when the sha256 of the original file matches the one it was made from. When Google ships a new build the files change, the patches stop applying silently and boot gets slower, so the logs state it explicitly (NOT patched). A new Google build therefore needs the patches regenerated (see Updating).
Faster on newer CPUs
Machines that have the instructions natively never trap, so the emulation costs nothing there. The slowest case is a pre-2021 CPU such as the Whiskey Lake i5-8365U the project is tested on.