> > You are of course correct. I advised an integrity value just to
detect
> > a hardware or software fault. The check value would not protect
against an
> > attack.
>
> Fair enough, but why protect these bits specifically?
> E.g. disk corruption seems more likely (since it's bigger). Add
> in
"Michael S. Tsirkin" wrote on 03/31/2013 04:17:28 AM:
>
> You want to protect against someone who is able to
> manipulate some bits in the file (content) but not others (hash)?
> What's the attack you are trying to protect against here?
>
> I'm guessing the only result of extra checksums would b
> One thing I'd like to get clarity about is the following corner-case. A
> user supplies some VM image as persistent storage for the TPM. It
> contains garbage. How do we handle this case? Does the TPM then just
> start writing its state into this image or do we want to have some layer
> in p
> Yea it's not hard to invent a random format each time we write something
> on disk.
> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's
a
> better format for migration than what we have now. Once we have it in
> tree re-using it seems cleaner than maintaining some per-TPM
A few comments FWIW
When I first did TPM 1.2, I stored different parts of the TPM NV data
(permanent data, owner evict keys, defined space) in different files. It
got ugly and I eventually changed to one big blob, This was far more
portable, worked better for real flash memory, etc. It also h
