Can we add a different recovery reason when root filesystem has DMVERROR |
||
Issue descriptionFeature request for the event log and for BIOS screen: Right now if the root filesystem is "corrupted" we report the error: No bootable storage device in system | 0x5a It would be awfully nice if we could special case and give a different error message if the root filesystem has been self-corrupted with "DMVERROR". See drivers/md/dm-verity-chromeos.c Specifically if there are memory or CPU execution problems in the kernel then verity can get a hash failure. Verity responds to this failure by self-corrupting a partition. It would be nice if we could easily identify this case in the BIOS.
,
Feb 16 2017
edit: Actually, I'm sorry, I spoke too soon. This is more tricky than you think. When a kernel fails to verify (e.g. due to DMVERROR), vboot marks that partition as "bad" in the GPT (sets tries and priority to 0). This means that on the next boot it won't even read that keyblock from disk anymore. I believe this is a boot speed optimization, so we probably wouldn't want to get rid of it. We could instead try to add a new GPT flag just for DMVERROR that is set either by the kernel directly or by the firmware when the verification first fails. Or we could after we find no good kernel (so we already no longer care about speed) scan all the available partitions again to see if any of them have a DMVERROR. But it would be a little more complicated either way.
,
Feb 18 2017
@2: Thanks for the clarification! The lab was specifically seeing (0x5a) and I was thinking that it was because of the DMVERROR corruption, but maybe it wasn't after all. Hrm. In any case, if we had a special case for DMVERROR then at least I wouldn't try to blame other errors on it. :-P Any way we could go back and see if it was DMVERROR if we totally fail? That wouldn't need to be fast...
,
Mar 31 2017
,
Jun 14 2018
Issue 716805 has been merged into this issue. |
||
►
Sign in to add a comment |
||
Comment 1 by jwer...@chromium.org
, Feb 16 2017Summary: Can we add a different recovery reason when root filesystem has DMVERROR (was: Can we add a different eventlog when root filesystem has DMVERROR)
Slight fix to the subject... it's really the recovery reason you want to change (which also gets put in the eventlog). Also, are you sure that you currently get 0x5a ("no bootable storage device") in that case? I would think it should be 0x5b ("no bootable kernel"). Actually, it looks like we already have some ancient code from Randall (as part of https://chromium-review.googlesource.com/c/4676/1/firmware/lib/vboot_kernel.c) in LoadKernel() that tries to differentiate this case a little more (that's what we have VBNV_RECOVERY_RW_INVALID_OS and VBNV_RECOVERY_RW_NO_OS allocated for), it just doesn't work right now because it gets overwritten at the end of VbTryLoadKernel() again. Shouldn't be too hard to fix that up... then we can add this as just another case that does a quick memcmp(). (And while we're there we should also add "TPM kernel rollback" as a separately detected case.)