Attention is currently required from: Furquan Shaikh, Aseda Aboagye. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/54304 )
Change subject: vboot/secdata_mock: Make v0 kernel secdata context ......................................................................
Patch Set 2:
(2 comments)
File src/security/vboot/secdata_mock.c:
https://review.coreboot.org/c/coreboot/+/54304/comment/f680e3bd_4dd1a379 PS1, Line 31: /* Vboot implicitly assumes that EFS2 (Early Firmware Selection v2) is
Thank you. I'd never seen the latter before so I got confused.
You should've been here for the great comment style wars of 2018. Some people really care *a lot* about where asterisks should and shouldn't go. ;)
File src/security/vboot/secdata_mock.c:
https://review.coreboot.org/c/coreboot/+/54304/comment/6bad5129_589349d4 PS2, Line 32: Vboot implicitly assumes that for EFS2 (Early Firmware Selection v2) : * systems, secdata is stored between reboots. Sorry, this still doesn't really feel accurate to me. vboot always assumes that secdata is stored between reboots (that's the whole point of having it). secdata v1 is where it really prevents you from booting when you don't. EFS2 isn't really the main issue here.
How about
The new kernel secdata v1 stores the last read EC hash, and reboots the device during EC software sync when that hash didn't match the currently active hash on the EC (this is used with TPM_CR50 to support EC-EFS2 and pretty much a no-op for other devices). Generally, of course the whole point of secdata is always that it persists across reboots, but with MOCK_SECDATA we can't do that. Previously we always happened to somewhat get away with presenting freshly-reinitialized data for MOCK_SECDATA on every boot, but with the EC hash feature in secdata v1, that would cause a reboot loop. The simplest solution is to just pretend we're a secdata v0 device when using MOCK_SECDATA.
-
Julius Werner (Code Review)