The document discusses securing hibernation snapshots on machines with UEFI secure boot enabled. It proposes using the shim bootloader to generate a key pair, with the private key stored in an EFI variable and passed to the kernel to sign hibernation snapshots. When restoring from hibernation, the kernel would verify the signature using the public key. Performance tests on hash algorithms like SHA-1 and SHA-512 are also presented.

1. Signature verification of
hibernate snapshot
September, 2013, LPC 2013, New Orleans
Joey Lee

2. Problem
●
●
On a multi-boot machine, hacker use any hole in
another UEFI trusted OS to modify the hibernate
snapshot image in swap partition.
Through uswsusp, userspace can take the
snapshot of memory then modify it. Upload it
back to memory then trigger the restore.
© SUSE, All rights reserved.

3. Idea
●
●
●
Jiri Kosina: Let EFI bootloader generates keypair then pass to kernel for sign hibernate
image.
Fundamental point: Trust the boot time
variable is secure when UEFI secure boot
enabled.
Attempt to protect snapshot image integrity.
© SUSE, All rights reserved.

4. Steps (when hibernate)
●
●
●
●
shim bootloader geneates key-pair and put keys
to non-volatile boot time varaibles.
EFI stub kernel loads private key before
ExitBootServices().
Hibernate subsystem copy the private key to a
empty page to keep it for sign snapshot when
hibernate launched.
Kernel generates signature of snapshot image
then put the signature to snapshot header.
Current reserved max size of signature is 512
bytes.
© SUSE, All rights reserved.

5. Steps (when hibernate restore)
●
●
After hibernate loaded snapshot image from
swap to temporary memory space, kernel uses
the public key from runtime volatile variable to
verify the signature that's stored in snapshot
header.
Then depend on sig_enforce
●
●
OFF: taint kernel and produce complain log
when signature check fail
ON: fail the hiberntae restore, then finish
boot process when signature check fail.
© SUSE, All rights reserved.

6. How to enable sig_enforce?
●
●
Use snapshot_sig_enforce kernel parameter.
Set kernel config then enable UEFI secure boot:
EFI_SECURE_BOOT_SNAPSHOT_SIG_ENFO
RCE
© SUSE, All rights reserved.

7. EFI variable name and GUID
●
GUID:
●
●
S4SignKey [BT][NV]→ private key
●
●
fe141863-c070-478e-b8a3-878a5dc9ef21
PKCS#8 _uncompressed_ private key format
S4WakeKey [RT][V] → public key
●
X.509 format
© SUSE, All rights reserved.

8. When shim should generate keys?
●
●
When system boot, and shim didn't find key-pair
When shim found GenS4Key EFI variable from
kernel:
●
●
●
GenS4Key-fe141863-c070-478e-b8a3878a5dc9ef21
[RT][NV]
Kernel or userspace write GenS4Key
variable to '1' when hibernate launched.
Kernel will delete GenS4Key in system boot.
© SUSE, All rights reserved.

9. Implementation Parts
●
Key-pair generator in shim
●
●
●
Author: Gary Lin
https://github.com/lcp/shim/tree/s4-key-upstream
Asymmetric Keys in Kernel:
●
●
●
Implemented PKCS#8 and PKCS#1 RSA private key parser
Add signature generation API and implement signature
generation logic in PKCS#1 (RFC3447 sec 8.2.2)
Hibernate in Kernel:
●
CONFIG_SNAPSHOT_VERIFICATION=y
●
Maintain and forward private key.
●
Avoid private key included in snapshot image.s
●
Sign snapshot image: generate signature then put it to snapshot
header.
© SUSE, All rights reserved.

10. Performance of hash (machine 1)
●
CPU:
●
●
●
Intel(R) Core(TM) i5 CPU
x86_64, ssse3
Normal
●
SHA1: 150.80 MB/s
●
SHA256: 59.19 MB/s
●
●
650 @ 3.20GHz
SHA512: 78.44 MB/s
Builded ssse3 support (v3.10 later)
●
SHA1: 195.60 MB/s
●
SHA256: 82.76 MB/s
●
SHA512: 120.60 MB/s
© SUSE, All rights reserved.

11. Performance of hash (machine 2)
●
CPU:
●
●
●
Intel(R) CPU @ 2.60GHz
x86_64, ssse3, avx, avx2
Normal
●
●
SHA256: 163.23 MB/s
●
●
SHA1: 436.42 MB/s
SHA512: 228.67 MB/s
Builded ssse3, avx, avx2 support (v3.10 later)
●
SHA1: 609.66 MB/s <=== fastest
●
SHA256: 242.03 MB/s
●
SHA512: 344.87 MB/s <=== more secure
© SUSE, All rights reserved.

12. Performance of hash (summary)
●
Speed between SHA1, SHA256, SHA512
●
●
SHA1 is 1.8 times of SHA512
●
●
SHA1 is 2.5 times of SHA256
SHA512 is 1.4 times of SHA256
Enabled ssse3
●
●
39% improved on SHA256
●
●
29% improved on SHA1
53% improved on SHA512
Enabled ssse3, avx, avx2
●
39% improved on SHA1
●
48% improved on SHA256
●
50% improved on SHA512
© SUSE, All rights reserved.

13. Performance of hash (summary)
●
Machine 1:
●
Best performance
–
–
●
SHA1: 195.60 MB/s on ssse3, avx, avx2
snapshot image grown to 3GB, then need 15.7 seconds for hash
SHA512's best performance
–
–
●
120.60 MB/s on ssse3, avx, avx2
snapshot image grown to 3GB, then need 25.4 seconds for hash
Machine 2:
●
Best performance
–
–
●
SHA1: 609.66 MB/s on ssse3, avx, avx2
snapshot image grown to 3GB, then need 5 seconds for hash
SHA512's best performasnce
–
344.87 MB/s on ssse3, avx, avx2
–
snapshot image grown to 3GB, then need 8.9 seconds for hash
© SUSE, All rights reserved.

14. Patch status
●
V4 RFC patches sent to kernel upstream and openSUSE kernel for
reviewing:
●
●
●
[RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
https://lkml.org/lkml/2013/9/14/183
Following kernel experts gave suggestions:
●
Hibernate
●
Matt Fleming <matt@console-pimps.org>
EFI
●
●
Pavel Machek <pavel@ucw.cz>
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Asymmetric keys
Followed Pavel and Matt's suggestions, already fix in V2, V3 patches
© SUSE, All rights reserved.

15. TODO
●
V5 patches:
●
●
●
Implement Dmitry Kasatkin's suggestions to
Asymmetric keys.
Should we remove the kernel config to user
for select hash algorithms?
Function add:
●
●
Kernel pass random number seed by EFI
variable to shim.
Encript snapshot image before sign it?
© SUSE, All rights reserved.

16. Corporate Headquarters
Maxfeldstrasse 5
90409 Nuremberg
Germany
© SUSE, All rights reserved.
+49 911 740 53 0 (Worldwide)
+www.suse.com
Join us on:
www.opensuse.org

17. Unpublished Work of SUSE. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary, and trade secret information of SUSE.
Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of
their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated,
abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE. Any use or
exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a
product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making
purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document,
and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
The development, release, and timing of features or functionality described for SUSE products remains at the sole
discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at
any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in
this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries.
All third-party trademarks are the property of their respective owners.