於 四，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 -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
