On Wed, Sep 21, 2011 at 09:44:37PM -0400, Stefan Berger wrote: > On 09/19/2011 03:04 PM, Michael S. Tsirkin wrote: > >On Mon, Sep 19, 2011 at 12:22:02PM -0400, Stefan Berger wrote: > >>On 09/17/2011 03:28 PM, Michael S. Tsirkin wrote: > >>>On Fri, Sep 16, 2011 at 12:46:40PM -0400, Stefan Berger wrote: > >> > >>The checksuming I think makes sense if encryption is being added so > >>decryption and testing for proper key material remains an NVRAM > >>operation rather than a device operation. > >Not sure how this addresses the question of what to do > >on checksum failure. > > > Checksum failure on an unencrypted blob would mean that the blob is > corrupted. In case of encryption 'corrupted' would overlap with a > 'badly decrypted' blob. In either way the startup of the device > cannot happen.
With corruption - why not? A specific block being corrupted does not mean all data is lost. > We could refuse the NVRAM key suggesting that likely > this is the wrong key for decryption but corruption is also > possible. I'm guessing that if we find a correct ber structure in the file, this most likely means the key is correct. -- MST