Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot

[joeyli <jlee@suse.com>]

於 四，2013-09-26 於 14:06 +0200，Pavel Machek 提到：
> Hi!
> 
> > For the symmetric key solution, I will try HMAC (Hash Message
> > Authentication Code). It's already used in networking, hope the
> > performance is not too bad to a big image.
> 
> Kernel already supports crc32 of the hibernation image, you may want
> to take a look how that is done.

In current kernel design, The crc32 is only for the LZO in-kernel
hibernate, doesn't apply to non-compress hibernate and userspace
hibernate.

Put signature to snapshot header can support any kind of caller that's
trigger hibernate. Any userspace hibernate tool will take the snapshot
image from kernel, so, we need put the signature(or hash result) to
snapshot header before userspace write it to anywhere. 

> 
> Maybe you want to replace crc32 with cryptographics hash (sha1?) and
> then use only hash for more crypto? That way speed of whatever crypto
> you do should not be an issue.

That speed of hash is calculated from non-compress snapshot image, does
not overlap with crc32.

> 
> Actually...
> 
> Is not it as simple as storing hash of hibernation image into NVRAM
> and then verifying the hash matches the value in NVRAM on next
> startup? No encryption needed. 
> 
> And that may even be useful for non-secure-boot people, as it ensures
> you boot right image after resume, boot it just once, etc...
> 
> 									Pavel

The HMAC approach will not encrypt, just put the key of HMAC to boottime
variable. 

If user doesn't enable UEFI secure boot, that's fine, the key of HMAC
still cannot access in OS runtime. 
If user enable UEFI secure boot, then that's better! Because all EFI
file will signed by the manufacturers or OSVs to make sure the code is
secure, will not pass the key to runtime.


Thanks a lot!
Joey Lee