| Message ID | 152346392521.4030.5108539377959227838.stgit@warthog.procyon.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed 2018-04-11 17:25:25, David Howells wrote: > From: Josh Boyer <jwboyer@fedoraproject.org> > > There is currently no way to verify the resume image when returning > from hibernate. This might compromise the signed modules trust model, > so until we can work with signed hibernate images we disable it when the > kernel is locked down. I'd rather see hibernation fixed than disabled like this. I believe Jiri Kosina may have some patches for that? Pavel
Pavel Machek <pavel@ucw.cz> wrote: > > There is currently no way to verify the resume image when returning > > from hibernate. This might compromise the signed modules trust model, > > so until we can work with signed hibernate images we disable it when the > > kernel is locked down. > > I'd rather see hibernation fixed than disabled like this. The problem is that you have to store the hibernated kernel image encrypted, but you can't store the decryption key on disk unencrypted or you've just wasted the effort. So the firmware has to unlock the image, asking the user for a password to unlock the key. David -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 19, 2018 at 7:38 AM, David Howells <dhowells@redhat.com> wrote: > Pavel Machek <pavel@ucw.cz> wrote: > >> > There is currently no way to verify the resume image when returning >> > from hibernate. This might compromise the signed modules trust model, >> > so until we can work with signed hibernate images we disable it when the >> > kernel is locked down. >> >> I'd rather see hibernation fixed than disabled like this. > > The problem is that you have to store the hibernated kernel image encrypted, > but you can't store the decryption key on disk unencrypted or you've just > wasted the effort. > > So the firmware has to unlock the image, asking the user for a password to > unlock the key. Why firmware? Either the boot kernel could figure out how to ask for a password (or unseal using the TPM) or we could defer this to userspace. The latter should already work using kexec-jump, no? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu 2018-04-19 15:38:53, David Howells wrote: > Pavel Machek <pavel@ucw.cz> wrote: > > > > There is currently no way to verify the resume image when returning > > > from hibernate. This might compromise the signed modules trust model, > > > so until we can work with signed hibernate images we disable it when the > > > kernel is locked down. > > > > I'd rather see hibernation fixed than disabled like this. > > The problem is that you have to store the hibernated kernel image encrypted, > but you can't store the decryption key on disk unencrypted or you've just > wasted the effort. That's not how the crypto needs to work. Talk to Jiri Kosina, ok? Firmware gives you a key, you keep it secret, use it to sign the hibernation image on suspend, and verify the signature on resume. Or something like that. Pavel
On Thursday, April 26, 2018 9:26:46 AM CEST Pavel Machek wrote: > On Thu 2018-04-19 15:38:53, David Howells wrote: > > Pavel Machek <pavel@ucw.cz> wrote: > > > > > > There is currently no way to verify the resume image when returning > > > > from hibernate. This might compromise the signed modules trust model, > > > > so until we can work with signed hibernate images we disable it when the > > > > kernel is locked down. > > > > > > I'd rather see hibernation fixed than disabled like this. > > > > The problem is that you have to store the hibernated kernel image encrypted, > > but you can't store the decryption key on disk unencrypted or you've just > > wasted the effort. > > That's not how the crypto needs to work. Talk to Jiri Kosina, ok? > > Firmware gives you a key, you keep it secret, use it to sign the > hibernation image on suspend, and verify the signature on resume. Or > something like that. A simplified approach might be to encrypt the image during hibernation using a user-provided passphrase and then ask for that passphrase during resume to decrypt the image. The attacker would then need to know the passphrase to substitute their own image for the original one successfully. -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 26 Apr 2018, Pavel Machek wrote:
> That's not how the crypto needs to work. Talk to Jiri Kosina, ok?
Yeah, Joey Lee (adding to CC) implemented it here:
https://lkml.org/lkml/2015/8/11/47
I think there have been more respins, Joey definitely knows more details
and status quo.
The design is specifically tailored for secure-boot environments though.
Hi experts, Sorry for I missed this discussion... On Thu, Apr 26, 2018 at 10:20:29AM +0200, Jiri Kosina wrote: > On Thu, 26 Apr 2018, Pavel Machek wrote: > > > That's not how the crypto needs to work. Talk to Jiri Kosina, ok? > > Yeah, Joey Lee (adding to CC) implemented it here: > > https://lkml.org/lkml/2015/8/11/47 > > I think there have been more respins, Joey definitely knows more details > and status quo. > > The design is specifically tailored for secure-boot environments though. > I am working on the next version of hibernation encryption and authentication: https://github.com/joeyli/linux-s4sign/wiki My plan is: - Hibernation encryption: There is a draft patch to encrypt image by ctr(aes). This patch works with the first version of hibernation verification: https://github.com/joeyli/linux-s4sign/commit/6a9a0113bb221c036ebd0f6321b7191283fe4929 - Adapt hibernation to key retention service: - Using the encrypted key to derive encrypt key and auth key to encrypt and hmac snapshot image. Put the encrypted key in the image header of snapshot. - The encrypted key will be encrypted by KMK (kernel master key). Either trusted key(sealed by TPM) or EFI key (explain in later) can be the KMK. If there have appropriate UI support in initrd, user key can also be the KMK. - Similar with the enrolling EVM key, but more earler: The systemd and dracut must be changed for enrolling kernel master key before the swap partition be mounted. - EFI key: - A new master key type to key retention service. - It can be a new option beyond trusted key(TPM) and user key. - EFI stub generates a random key and stores in EFI boot service variable: - This random key in boot variable can be called ERK (EFI Root Key) - The ERK is secure when secure boot enabled. - User must aware and enable secure boot by themself if they want. - ERK can be a secret to encrypt a random number for generate a EFI key - The EFI key can be used by hibernation encryption/authentication. - The EFI key can be a master key to generate a encrypted key for EVM. - Rescue mechanism for ERK: - The ERK may be regenerated after the old ERK be erased by firmware update or firmware recovery. - Current idea is using the public key in first/second trusted keyring to encrypt the ERK for backup. User can enroll the EFI key with old ERK to request kernel to re-encrypt the EFI key with new ERK. Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c index 5454cc639a8d..629f158f5a0c 100644 --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -70,7 +70,7 @@ static const struct platform_hibernation_ops *hibernation_ops; bool hibernation_available(void) { - return (nohibernate == 0); + return nohibernate == 0 && !kernel_is_locked_down("Hibernation"); } /**