Hello all,
Intended change:
When a corrupted block is detected on a verity device, when
calculating the hash of a block, which is unequal to the
verity_io_want_digest, (dm-verity-target.c@563) in which case the
verity_handle_data_mismatch function logs the number of the affected block.
The change could look similar to this sketch starting from
dm-verity-target.c@486
dm_audit_log_bio(DM_MSG_PREFIX, "verify-data", bio, blkno, 0);
#ifdef CONFIG_TCG_TPM //Could also check if flag is set for this
feature in verity's invocation
chip = tpm_chip_alloc();
tpm_pcr_extend(chip, PCR_VERITY_ERROR, blkno);
// Which of the 24 PCR to use can be decided later. As far as I
know 0-7 is reserved for Firmware and 8-15 for Kernel or systemd
features etc.
dev_err(dev, "%s: tpm_chip_alloc failed\n", __func__);
#endif
return -EIO;
The reasoning:
In light of the surge of TPMs used in other Operating Systems or systems
in general, it would be great to integrate the option of working with a
TPM in as many areas as possible in the system. This change specifically
has quite a few useful benefits for secure system design.
To put it concisely, currently DM-Verity does not have a whole lot of
options in regards to dealing with corruption. Panic or restart is
rarely a viable option for most systems, while logging itself does not
have any impact on the security, unless the logs are used for further
investigation / threat analysis. It is that which would be greatly
enhanced if verity would also directly log to a TPM when configured.
This would open up verity to a wide range of possibilities for dealing
with corruption, for example local investigation into the criticality of
the corruption / tying access rights managed by the TPM to which block
has been corrupted (e.g user vs root directories etc.) but also remote
attestation, sending the corrupted blocks to a central IDS-like service
to analyse which parts exactly have changed and weather this was a
deliberate attack or perhaps a hardware/software malfunction.
Lastly there is also a second section in the code where a verity error
is logged. In dm-verity-target.c@362 in the verity_verify_level
function, as far as I can tell, the whole metadata block is logged. I
would like to ask for some feedback, weather this would also be a good
candidate to be captured in the TPM.
Thank you for reading.
--
Jonathan Witt
