summaryrefslogtreecommitdiff
path: root/Documentation/doxygen
diff options
context:
space:
mode:
authorAndrey Pronin <apronin@google.com>2018-01-26 12:47:51 -0800
committerVadim Bendebury <vbendeb@chromium.org>2018-02-07 02:37:25 +0000
commit278a5064b4a8e7c0a5742872a9d5b4464e22da00 (patch)
tree24bb201d966a87a00d41bcf38a9fb76de74fd194 /Documentation/doxygen
parente9628402820b88543443529fae87106f74689aa7 (diff)
security/vboot: overwrite existing spaces during factory init for tpm2
In TPM 2.0 case, if the factory initialization is interrupted after defining, say, the kernel tpm nvram space but before writing to this space, the following will happen upon reboot when the factory initialization will be re-attempted. Writing to this space will be skipped, and coreboot will finish the factory initialization with this space remained unwritten. At a later stage, when the rollback logic will attempt to check the version in the kernel space, it will fail (TPM2.0 returns an error when reading from unwritten spaces), and the system will go into recovery with no way out (since the kernel space will never be written). This change fixes that by always writing to the kernel, MRC hash and firmware spaces during factory initialization, even if the space already existed by that time. BUG=b:71884828 TEST=delete, define, but not write to the kernel space; trigger factory initialization; coreboot should fill the kernel space and continue booting. Change-Id: I48d8bb4f9fc0e5276e6ec81247b3b6768ec9fa3b Signed-off-by: Andrey Pronin <apronin@google.com> Reviewed-on: https://review.coreboot.org/23456 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Diffstat (limited to 'Documentation/doxygen')
0 files changed, 0 insertions, 0 deletions