Introduce the in-kernel hibernation encryption

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Quoted 2 lines · Chen Yu

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Which unfortunately means it can not reviewed.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi,

Quoted 7 lines · Pavel Machek

Quoted 2 lines · Chen Yu

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Quoted 5 lines

Which unfortunately means it can not reviewed.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

The advantages are described in detail in
[PATCH 1/4]'s log, please refer to that.

Quoted 11 lines · Yu Chen

Hi,

Quoted 9 lines · Pavel Machek

Quoted 2 lines · Chen Yu

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Which unfortunately means it can not reviewed.

Quoted 5 lines

Quoted 3 lines

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

The advantages are described in detail in
[PATCH 1/4]'s log, please refer to that.

Are you refering to this?

# Generally the advantage is: Users do not have to

# encrypt the whole swap partition as other tools.
# After all, ideally kernel memory should be encrypted
# by the kernel itself.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

Also note that joeyli <[email protected]> has patch series which encrypts both in-kernel and uswsusp hibernation methods. His motivation is secure boot. How does this compare to his work?

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 2 lines

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Which unfortunately means it can not reviewed.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

Quoted 5 lines

Quoted 2 lines

The advantages are described in detail in
[PATCH 1/4]'s log, please refer to that.

Are you refering to this?

Not this one. I've sent v2 of this patch set which explain more on this:
https://patchwork.kernel.org/patch/10532935/

Let me paste the log here:

1. (This is not to compare with uswsusp but other tools) One advantage is: Users do not have to encrypt the whole swap partition as other tools.

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

2.2 Not having to copy each page to user space
one by one not in parallel, which might introduce significant amount of copy_to_user() and it might not be efficient on servers having large amount of DRAM.

2.3 Distribution has requirement to do snapshot
signature for verification, which can be built by leveraging this patch set.

2.4 The encryption is in the kernel, so it doesn't
have to worry too much about bugs in user space utilities and similar, for example.

Quoted 4 lines

Also note that joeyli <[email protected]> has patch series which encrypts both in-kernel and uswsusp hibernation methods. His motivation is secure boot. How does this compare to his work?

Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature feature can be based on this patch set.

Hi!

Quoted 5 lines

Let me paste the log here:

1. (This is not to compare with uswsusp but other tools) One advantage is: Users do not have to encrypt the whole swap partition as other tools.

Well.. encrypting the partition seems like good idea anyway.

Quoted 7 lines

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:

Quoted 8 lines

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

Quoted 4 lines

2.2 Not having to copy each page to user space
one by one not in parallel, which might introduce significant amount of copy_to_user() and it might not be efficient on servers having large amount of DRAM.

So how big speedup can be attributed by not doing copy_to_user?

Quoted 3 lines

2.3 Distribution has requirement to do snapshot
signature for verification, which can be built by leveraging this patch set.

Signatures can be done by uswsusp, too, right?

Quoted 3 lines

2.4 The encryption is in the kernel, so it doesn't
have to worry too much about bugs in user space utilities and similar, for example.

Answer to bugs in userspace is _not_ to move code from userspace to kernel.

Quoted 4 lines

Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature feature can be based on this patch set.

Well, his work can also work without your patchset, right?

Quoted 16 lines

Quoted 15 lines

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

Quoted 3 lines

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Quoted 6 lines

Quoted 4 lines

Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature feature can be based on this patch set.

Well, his work can also work without your patchset, right?

Yes. But you are objecting to encryption in kernel space at all, aren't you?

Hi!

Quoted 16 lines

Quoted 16 lines

Quoted 15 lines

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

Quoted 6 lines

Quoted 3 lines

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Yes, that seems to be one of problems of Yu Chen's patchset.

Quoted 9 lines

Quoted 6 lines

Quoted 4 lines

Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature feature can be based on this patch set.

Well, his work can also work without your patchset, right?

Yes. But you are objecting to encryption in kernel space at all, aren't you?

I don't particulary love the idea of doing hibernation encryption in the kernel, correct.

But we have this weird thing called secure boot, some people seem to want. So we may need some crypto in the kernel -- but I'd like something that works with uswsusp, too. Plus, it is mandatory that patch explains what security guarantees they want to provide against what kinds of attacks...

Lee, Chun-Yi's patch seemed more promising. Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Quoted 6 lines

Quoted 2 lines

Yes. But you are objecting to encryption in kernel space at all, aren't you?

I don't particulary love the idea of doing hibernation encryption in the kernel, correct.

Quoted 8 lines

But we have this weird thing called secure boot, some people seem to want. So we may need some crypto in the kernel -- but I'd like something that works with uswsusp, too. Plus, it is mandatory that patch explains what security guarantees they want to provide against what kinds of attacks...

Lee, Chun-Yi's patch seemed more promising. Pavel

The only difference between Chun-Yi's hibernation encrytion solution and our solution is that his strategy encrypts the snapshot from sratch, and ours encryts each page before them going to block device. The benefit of his solution is that the snapshot can be encrypt in kernel first thus the uswsusp is allowed to read it to user space even kernel is lock down. And I had a discussion with Chun-Yi that we can use his snapshot solution to make uswsusp happy, and we share the crypto help code and he can also use our user provided key for his signature.

Quoted 1 line

From this point of view, our code are actually the same, except that

we can help clean up the code and also enhance some encrytion process for his solution. I don't know why you don't like encryption in kernel, because from my point of view, without encryption hibernation in kernel, uswsusp could not be enabled if kernel is lock down : -) Or do I miss something?

Quoted 2 lines

Yes. But you are objecting to encryption in kernel space at all, aren't you?

I don't particulary love the idea of doing hibernation encryption in the kernel, correct.

But we have this weird thing called secure boot, some people seem to want. So we may need some crypto in the kernel -- but I'd like something that works with uswsusp, too. Plus, it is mandatory that patch explains what security guarantees they want to provide against what kinds of attacks...

Quoted 11 lines · Pavel Machek

Quoted 2 lines

Yes. But you are objecting to encryption in kernel space at all, aren't you?

I don't particulary love the idea of doing hibernation encryption in the kernel, correct.

But we have this weird thing called secure boot, some people seem to want. So we may need some crypto in the kernel -- but I'd like something that works with uswsusp, too. Plus, it is mandatory that patch explains what security guarantees they want to provide against what kinds of attacks...

Hi,

very well, maybe we should state clearly that the goal of these patch set is to make Secure Boot and STD coexist. Anything else is a nice side effect, but not the primary justification, right?

And we further agree that the model of Secure Boot requires the encryption to be done in kernel space, don't we? Furthermore IMHO the key must also be generated in trusted code, hence in kernel space. Yu Chen, I really cannot see how a symmetrical encryption with a known key can be secure.

Quoted 1 line · Pavel Machek

Hi!

Hello,

Quoted 2 lines

Quoted 2 lines

Let me paste the log here:

Quoted 5 lines

Quoted 3 lines

1. (This is not to compare with uswsusp but other tools) One advantage is: Users do not have to encrypt the whole swap partition as other tools.

Well.. encrypting the partition seems like good idea anyway.

Yes, but it is a policy decision the kernel should not force. STD needs to work anyway.

Quoted 16 lines

Quoted 15 lines

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

Quoted 3 lines

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Quoted 6 lines

Quoted 4 lines

2.2 Not having to copy each page to user space
one by one not in parallel, which might introduce significant amount of copy_to_user() and it might not be efficient on servers having large amount of DRAM.

So how big speedup can be attributed by not doing copy_to_user?

That would be an argument for compression in kernel space. Not encrpting would always be faster.

Quoted 5 lines

Quoted 3 lines

2.3 Distribution has requirement to do snapshot
signature for verification, which can be built by leveraging this patch set.

Signatures can be done by uswsusp, too, right?

Not if you want to keep the chain of trust intact. User space is not signed.

Quoted 5 lines

Quoted 3 lines

2.4 The encryption is in the kernel, so it doesn't
have to worry too much about bugs in user space utilities and similar, for example.

Answer to bugs in userspace is _not_ to move code from userspace to kernel.

Indeed.

Quoted 6 lines

Quoted 4 lines

Joey Lee and I had a discussion on his previous work at
https://patchwork.kernel.org/patch/10476751
We collaborate on this task and his snapshot signature feature can be based on this patch set.

Well, his work can also work without your patchset, right?

Yes. But you are objecting to encryption in kernel space at all, aren't you?

Regards
Oliver

Hi,

Quoted 9 lines · Oliver Neukum

Quoted 3 lines · Pavel Machek

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 9 lines

Quoted 8 lines

Quoted 4 lines

"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

Quoted 3 lines

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.

Hi!

Quoted 13 lines

Quoted 12 lines

Quoted 8 lines

Quoted 4 lines

"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Quoted 4 lines

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.

Safe against what kind of attack? Please describe what kind of security you are trying to provide.

I don't think generating key in userspace is good enough for providing guarantees for secure-boot.

Quoted 15 lines · Pavel Machek

Hi!

Quoted 13 lines

Quoted 12 lines

Quoted 8 lines

Quoted 4 lines

"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Quoted 7 lines

Quoted 4 lines

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.

Safe against what kind of attack? Please describe what kind of security you are trying to provide.

Unsigned code must not take over the priviledge level of signed code. Hence:

1. Unsigned code must not allowed to read sensitive parts of signed code's memory space

2. Unsigned code must not be able to alter the memory space of signed code -> snapshots that are changed must not be able to be resumed

Quoted 2 lines

I don't think generating key in userspace is good enough for providing guarantees for secure-boot.

Why?

Quoted 1 line · Oliver Neukum

On Di, 2018-07-24 at 14:01 +0200, Pavel Machek wrote:

Quoted 6 lines

Quoted 2 lines

Safe against what kind of attack? Please describe what kind of security you are trying to provide.

Unsigned code must not take over the priviledge level of signed code. Hence:

Quoted 6 lines

1. Unsigned code must not allowed to read sensitive parts of signed code's memory space

2. Unsigned code must not be able to alter the memory space of signed code -> snapshots that are changed must not be able to be resumed

Ok.

Quoted 4 lines

Quoted 2 lines

I don't think generating key in userspace is good enough for providing guarantees for secure-boot.

Why?

Because then, userpace has both key (now) and encrypted image (after reboot), so it can decrypt, modify, re-encrypt...?

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Hi all,

Quoted 44 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

Quoted 4 lines

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566 

My next step is that cleaning up the my EFI key type patches and submit it to EFI/keys subsystem ASAP. Then I will clean up my hibernation encryption/authentication solution for reviewing.

Thanks
Joey Lee

Hi Joey,

Quoted 52 lines · joeyli

Hi all,

Quoted 48 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Quoted 5 lines

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566 

Thanks for the work, I have two questions here:

1. Could you please describe a little more about the scenario on
how the user could use the secret key for hibernation encryption?
A requirement is that, the user should provide a passphrase(for key derivation, i.e.) during resume. I was thinking how user could interact with
the security key mechanism here.

2. The generation of secret key in EFI boot environment is using a non standard derivation method in generate_secret_key(), I'm not sure if this is safe enough. This is why we tried to put PBKDF2 into kernel at first and leave it to the user space then.

Quoted 54 lines · Yu Chen

Hi Joey,

Quoted 52 lines · joeyli

Hi all,

Quoted 48 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Quoted 6 lines

Quoted 5 lines

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566

Thanks for the work, I have two questions here:

My EFI key patch set is almost done. I will send it soon.

Quoted 6 lines

1. Could you please describe a little more about the scenario on
how the user could use the secret key for hibernation encryption?
A requirement is that, the user should provide a passphrase(for key derivation, i.e.) during resume. I was thinking how user could interact with
the security key mechanism here.

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Quoted 5 lines

2. The generation of secret key in EFI boot environment is using a non standard derivation method in generate_secret_key(), I'm not sure if this is safe enough. This is why we tried to put PBKDF2 into kernel at first and leave it to the user space then.

Thank you for point out.

The generate_secret_key() reuse the logic in kaslr_get_random_long() that it produces random seed by RDRAND, RDTSC and i8254. It doesn't standard like PBKDF2, but we do not have too many choices in the early boot stage. At least KASLR is using the same logic.

We can relay on user space helper. But the helper must be authenticated by kernel. Currently we do not have kernel mechanism to verity user space process.

Regards
Joey Lee

Quoted 56 lines · joeyli

Quoted 54 lines · Yu Chen

Hi Joey,

Quoted 52 lines · joeyli

Hi all,

Quoted 48 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566

Thanks for the work, I have two questions here:

My EFI key patch set is almost done. I will send it soon.

Okay, please send them out then we can have further discussion on that.

Quoted 7 lines

Quoted 6 lines

1. Could you please describe a little more about the scenario on
how the user could use the secret key for hibernation encryption?
A requirement is that, the user should provide a passphrase(for key derivation, i.e.) during resume. I was thinking how user could interact with
the security key mechanism here.

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the key and encrypted the hibernation snapshot and stores it on the disk . Then if user
B wants to do a hibernation resume to A's previous environment, B has to provide the same passphrase.
If I understand correctly, the secret key is saved in header and stored on the disk. Which means, any one can read the header from the disk to get the secret key in trampoline thus decrypt the image, which is not safe.

Quoted 80 lines · Ryan Chen

Quoted 56 lines · joeyli

Quoted 54 lines · Yu Chen

Hi Joey,

Quoted 52 lines · joeyli

Hi all,

Quoted 48 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566

Thanks for the work, I have two questions here:

My EFI key patch set is almost done. I will send it soon.

Okay, please send them out then we can have further discussion on that.

Quoted 7 lines

Quoted 6 lines

1. Could you please describe a little more about the scenario on
how the user could use the secret key for hibernation encryption?
A requirement is that, the user should provide a passphrase(for key derivation, i.e.) during resume. I was thinking how user could interact with
the security key mechanism here.

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Quoted 13 lines

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the key and encrypted the hibernation snapshot and stores it on the disk . Then if user
B wants to do a hibernation resume to A's previous environment, B has to provide the same passphrase.
If I understand correctly, the secret key is saved in header and stored on the disk. Which means, any one can read the header from the disk to get the secret key in trampoline thus decrypt the image, which is not safe.

The secret key that it's saved in snapshot header is a session key which is encrypted by ERK (EFI root key). The ERK only lives in kernel space. So the session key is still secure.

When resume, the session key will be decrypted/verified by ERK. Then kernel uses the session key to decrypted/verified snapshot image.

Of course that we can direct use ERK to encrypt/authenticate snapshot image. Actually the first version of hibernation verification in SLE direct uses ERK. So the snapshot header only keeps signature but no encrypted session key.

I add session key in new version because I want to align with the use case of TPM trusted key + encrypted key. Then hibernation can use key retention service API to access EFI key or encrypted key.

Compare the trusted key with EFI secure key:

TPM SRK ----seal-----> Trusted key ---encrypt---> Encrypted key
ERK ---encrypt---> EFI secure key ---encrypt---> Encrypted key

Both of them can be the master key of encrypted key.

If EFI key can not be accepted by kernel community, then the TPM trusted key + encrypted key will be the only solution. We can very easy to switch to encrypted key by using key retention service API.

Thanks a lot!
Joey Lee

Quoted 96 lines · joeyli

Quoted 80 lines · Ryan Chen

Quoted 56 lines · joeyli

Quoted 54 lines · Yu Chen

Hi Joey,

Quoted 52 lines · joeyli

Hi all,

Quoted 48 lines · joeyli

Quoted 17 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative. The whole point of Secure Boot is a cryptographic system of trust that does not include user space.

Quoted 7 lines

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Crurently there have two solutions, they are trusted key and EFI key. Both of them are generated in kernel and are not visible in user space.

The trusted key is generated by kernel then sealed by the TPM's SRK. So the trusted key can be stored in anywhere then be enrolled to kernel when we need it. EVM already uses it.

The EFI key is Jiri Kosina's idea. It is stored in boot services variable, which means that it can only be access by signed EFI binary (e.g. signed EFI boot stub) when secure boot be enabled. SLE applied this solution a couple of years.

I am working on put the EFI key to key retention service. Then EFI key can be a master key of encrypted key. EVM can also use it:
https://github.com/joeyli/linux-s4sign/commit/bae39460393ada4c0226dd07cd5e3afcef86b71f
https://github.com/joeyli/linux-s4sign/commit/f552f97cc3cca5acd84f424b7f946ffb5fe8e9ec

That's why I want to use key retention service in hibernation encryption/authentication. Which means that we can use key API to access trusted key and EFI key.

Quoted 9 lines

Quoted 6 lines

Quoted 5 lines

Here is a proof of concept for using the key retention service to encrypt/sign snapshot image. It's using EFI key now, I will add encrypted key support in the key handler later:

    https://github.com/joeyli/linux-s4sign/commit/6311e97038974bc5de8121769fb4d34470009566

Thanks for the work, I have two questions here:

My EFI key patch set is almost done. I will send it soon.

Okay, please send them out then we can have further discussion on that.

Quoted 7 lines

Quoted 6 lines

1. Could you please describe a little more about the scenario on
how the user could use the secret key for hibernation encryption?
A requirement is that, the user should provide a passphrase(for key derivation, i.e.) during resume. I was thinking how user could interact with
the security key mechanism here.

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Quoted 13 lines

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the key and encrypted the hibernation snapshot and stores it on the disk . Then if user
B wants to do a hibernation resume to A's previous environment, B has to provide the same passphrase.
If I understand correctly, the secret key is saved in header and stored on the disk. Which means, any one can read the header from the disk to get the secret key in trampoline thus decrypt the image, which is not safe.

Quoted 7 lines

The secret key that it's saved in snapshot header is a session key which is encrypted by ERK (EFI root key). The ERK only lives in kernel space. So the session key is still secure.

When resume, the session key will be decrypted/verified by ERK. Then kernel uses the session key to decrypted/verified snapshot image.

OK, I see.

Quoted 11 lines

Of course that we can direct use ERK to encrypt/authenticate snapshot image. Actually the first version of hibernation verification in SLE direct uses ERK. So the snapshot header only keeps signature but no encrypted session key.

I add session key in new version because I want to align with the use case of TPM trusted key + encrypted key. Then hibernation can use key retention service API to access EFI key or encrypted key.

Compare the trusted key with EFI secure key:

Quoted 5 lines

TPM SRK ----seal-----> Trusted key ---encrypt---> Encrypted key
ERK ---encrypt---> EFI secure key ---encrypt---> Encrypted key

Both of them can be the master key of encrypted key.

So either Trusted key or EFI secure key(session key) could be used for snapshot encryption, right?

Quoted 5 lines

If EFI key can not be accepted by kernel community, then the TPM trusted key + encrypted key will be the only solution. We can very easy to switch to encrypted key by using key retention service API.

Back to question raised previously, how could TPM or EFI key be used to prevent user B from resuming to the environment of A? It appears to me
that, although A is the user who launches the hibernation, B could
resume to the context of A because there's no certification during
resume. Is there any way to introduce the password based verification?

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Strange as it may sound, that is what "secure" boot requires (and what Disney wants).

I guess it may have some non-evil uses,
too... https://www.linux.com/news/matthew-garrett-explains-how-increase-security-boot-time

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

Quoted 3 lines

Strange as it may sound, that is what "secure" boot requires (and what Disney wants).

Ok, I understand this requirement, and I'm also concerning how to distinguish different users from seeing data of each other.

Joey,
I'm thinking of a possible direction which could take advantage of the password. It leverages either EFI key or TPM trusted key to get it done. Does it make sense?

1. The user space generates a symetric key key_user using the password, and passes the key_user to the kernel as the master key.
2. The kernel uses the EFI key or TPM trusted key to encrypt the key_user thus gets a encrypt_key.
3. Uses the encrypt_key to do snapshot encryption
4. During resume, the same encrypt_key is generated following the same steps(I assume the same EFI key or TPM key could be fetched during resumed, right?) and do the snapshot decryption.

And this is what fscrypt is doing:
Documentation/filesystems/fscrypt.rst

Quoted 20 lines · Yu Chen

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Quoted 6 lines

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

OK, I saw your case. This is a physical accessing.

I have a question: The suspend to memory also has the same behavior and more people are using suspend. Should we think a common solution to cover S3 and S4?

Quoted 11 lines

Quoted 3 lines

Strange as it may sound, that is what "secure" boot requires (and what Disney wants).

Ok, I understand this requirement, and I'm also concerning how to distinguish different users from seeing data of each other.

Joey,
I'm thinking of a possible direction which could take advantage of the password. It leverages either EFI key or TPM trusted key to get it done. Does it make sense?

Quoted 10 lines

1. The user space generates a symetric key key_user using the password, and passes the key_user to the kernel as the master key.
2. The kernel uses the EFI key or TPM trusted key to encrypt the key_user thus gets a encrypt_key.
3. Uses the encrypt_key to do snapshot encryption
4. During resume, the same encrypt_key is generated following the same steps(I assume the same EFI key or TPM key could be fetched during resumed, right?) and do the snapshot decryption.

Yes, we can use TPM key to protect the user key. But I suggest that we should give user a function to disable the user key because not everyone want to key-in a password for hibernate/resume and also snapshot image encryption.

Two policies:
- When user key-in user key, the snapshot image must be encryption.
- Without key-in user key, I still want the snapshot image can be encryption.

No matter that the user key be key-in or not, the snapshot image must be encrypted by a kernel key. So I suggest that we treat the user key as a salt for snapshot image encryption and authentication. If the user key be disabled, then kernel just generates a random number as a salt.

Actually, the kernel must compares the user key before snapshot decryption. If the user key doesn't match but user space still triggers furture resume process. Then kernel direct drops the snapshot image.

Quoted 3 lines

And this is what fscrypt is doing:
Documentation/filesystems/fscrypt.rst

The use case is different. We have two key for two purposes. And the two functions can be separated.

Thanks
Joey Lee

Quoted 28 lines · joeyli

Quoted 26 lines · Yu Chen

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

Quoted 6 lines

OK, I saw your case. This is a physical accessing.

I have a question: The suspend to memory also has the same behavior and more people are using suspend. Should we think a common solution to cover S3 and S4?

Since STD behaves more likely a boot up, STR does not have solid requirement for certification.

Quoted 36 lines

Quoted 11 lines

Quoted 3 lines

Strange as it may sound, that is what "secure" boot requires (and what Disney wants).

Ok, I understand this requirement, and I'm also concerning how to distinguish different users from seeing data of each other.

Joey,
I'm thinking of a possible direction which could take advantage of the password. It leverages either EFI key or TPM trusted key to get it done. Does it make sense?

Quoted 10 lines

1. The user space generates a symetric key key_user using the password, and passes the key_user to the kernel as the master key.
2. The kernel uses the EFI key or TPM trusted key to encrypt the key_user thus gets a encrypt_key.
3. Uses the encrypt_key to do snapshot encryption
4. During resume, the same encrypt_key is generated following the same steps(I assume the same EFI key or TPM key could be fetched during resumed, right?) and do the snapshot decryption.

Yes, we can use TPM key to protect the user key. But I suggest that we should give user a function to disable the user key because not everyone want to key-in a password for hibernate/resume and also snapshot image encryption.

Two policies:
- When user key-in user key, the snapshot image must be encryption.
- Without key-in user key, I still want the snapshot image can be encryption.

No matter that the user key be key-in or not, the snapshot image must be encrypted by a kernel key. So I suggest that we treat the user key as a salt for snapshot image encryption and authentication. If the user key be disabled, then kernel just generates a random number as a salt.

Quoted 4 lines

Actually, the kernel must compares the user key before snapshot decryption. If the user key doesn't match but user space still triggers furture resume process. Then kernel direct drops the snapshot image.

Anyway I'm ok with using TPM for major 'security', please feel free to send a second version out, and for certification implementation we can have further discussion on that later.

Quoted 20 lines · Yu Chen

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Quoted 6 lines

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

OK, I saw your case. This is a physical accessing.

I have a question: The suspend to memory also has the same behavior and more people are using suspend. Should we think a common solution to cover S3 and S4?

Quoted 30 lines · joeyli

Quoted 20 lines · Yu Chen

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Quoted 6 lines

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

OK, I saw your case. This is a physical accessing.

Quoted 3 lines

I have a question: The suspend to memory also has the same behavior and more people are using suspend. Should we think a common solution to cover S3 and S4?

Well, we have similar problem during runtime, too ;-).

Anyway, I don't think we should encrypt memory during S3 in kernel.

If you wanted to do that, you could use uswsusp to take snapshot, store it in ram, encrypt, erase originals (new API might be needed... hmm. does not exactly sound easy... kexec?), trigger S3, decrypt, resume from snapshot...

Sounds like a bit of work...

Best regards,

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi,

Quoted 35 lines · Pavel Machek

Quoted 33 lines · joeyli

Quoted 20 lines · Yu Chen

Hi Pavel,

Quoted 13 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

Quoted 5 lines

No, I don't think that's purpose here.

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Quoted 6 lines

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe user for password during resume, which sounds more natural.

OK, I saw your case. This is a physical accessing.

I have a question: The suspend to memory also has the same behavior and more people are using suspend. Should we think a common solution to cover S3 and S4?

Quoted 4 lines

Well, we have similar problem during runtime, too ;-).

Anyway, I don't think we should encrypt memory during S3 in kernel.

It seems that Joey was talking about certification(something like login) rather than encryption?

Quoted 13 lines

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

No, I don't think that's purpose here.

Quoted 3 lines

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe

Hi!

Quoted 13 lines

Quoted 13 lines

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

No, I don't think that's purpose here.

Quoted 8 lines

Quoted 3 lines

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe

Define unsafe.

If you want security against bad people resuming your machines, please

take a look at existing uswsusp solutions. It defends against that.

If you want security against bad people tampering with your machines physically, sorry, there's no way to defend against that.

But I thought you were trying to do something for secure boot, and "bad person resumes your machine" is out of scope there.

So please always explain security against _what kind of attack_ you are trying to improve; intelligent communication is not possible without that.

Quoted 3 lines

Define unsafe.

If you want security against bad people resuming your machines, please

Yes, this is one of the requirements.

Quoted 3 lines

But I thought you were trying to do something for secure boot, and "bad person resumes your machine" is out of scope there.

Not exactly, secure boot is one solution to meet the requirement.

Quoted 4 lines

So please always explain security against _what kind of attack_ you are trying to improve; intelligent communication is not possible without that.

User requirement:
A is the user, B is the attacker, user A launches a STD and encrypts A's ram data, then writes these encrypted data onto the disk, so that: Even if user B has access to the disk, B could not know the content of A. Which implies:
1. If B unplugs the disk from A's machine, and plugs the disk onto another machine, B could not decode the content without A's 'permission'.
2. If B is using the same machine as A, even A has walked away leaving the system suspend, B could not resume to A's context without A's 'permission'.

Previously, there are three proposal for this:
a. Enhance the uswsusp(Pavel)

Then let's talk a little more about secure boot. According to my understanding, the situation secure boot tries to deal with is a little different from the user case we raised above - It is an enhancement for case 1, because it refuses to resume once the machine is changed. And it does not cover case 2. But if it is a requirement from the user, that's ok.

User requirement:
A is the user, B is the attacker, user A launches a STD and encrypts A's ram data, then writes these encrypted data onto the disk, so that: Even if user B has access to the disk, B could not know the content of A. Which implies:
1. If B unplugs the disk from A's machine, and plugs the disk onto another machine, B could not decode the content without A's 'permission'.

2. If B is using the same machine as A, even A has walked away leaving the system suspend, B could not resume to A's context without A's 'permission'.

Previously, there are three proposal for this:
a. Enhance the uswsusp(Pavel)
b. Using user provided password to generate the key, for encryption(Yu) c. Using security boot(TPM or EFI key) for encryption(Joey)

Since I was proposing solution b, I'll say a little more about it. The original idea was that, the user provides a password, then this password is used to generate the key, which means, if user B has provided an incorrect password, the kernel will fail to decrypt the data and is likely to fail the resume process. That is to say, no matter which physical machine B is using, only if he has provided the password, he would be able to resume. In the first version, the key deviration was firstly done in kernel space, which satisfies the requirement and both saftey. Unfortunately it was rejected and people would like to see the key generated in user space instead. However, using user provided key directly is not safe, according to the discussion in the thread. I don't have good idea on how to improve this, but only have some workarounds, say, ask the kernel to use TPM key to protects the user provided 'key', etc.

Then let's talk a little more about secure boot. According to my understanding, the situation secure boot tries to deal with is a little different from the user case we raised above - It is an enhancement for case 1, because it refuses to resume once the machine is changed. And it does not cover case 2. But if it is a requirement from the user, that's ok.

uswsusp is to do all the staff in user space, and other two aim to do all the staff in kernel space. I'm not arguing which one is better, but I'm not sure how often user is using it, as we don't get uswsusp related bug report on kernel bugzilla (both internally)recent years. Another point is, why the compression is in kernel rather than in uswsusp, it looks like the same case as encryption here.

Hi Pavel, Joey, Oliver
Please let me describe the original requirement and my understanding about hibernation encryption here, thus help us sync on the same thread:

Quoted 24 lines · Pavel Machek

Hi!

Quoted 13 lines

Quoted 13 lines

Quoted 10 lines

Quoted 5 lines

User space doesn't need to involve. The EFI root key is generated by EFI boot stub and be transfer to kernel. It's stored in EFI boot service variable that it can only be accessed by trusted EFI binary when secure boot is enabled.

Okay, this apply to the 'suspend' phase, right?
I'm still a little confused about the 'resume' phase.
Taking encryption as example(not signature),
the purpose of doing hibernation encryption is to prevent other users from stealing ram content. Say, user A uses a passphrase to generate the

No, I don't think that's purpose here.

Quoted 8 lines

Quoted 3 lines

Purpose here is to prevent user from reading/modifying kernel memory content on machine he owns.

Say, A puts his laptop into hibernation and walks away, and B walks by, and opens A's laptop and wakes up the system and he can do what he wants. Although EFI key/TPM trusted key is enabled, currently there's no certification during resume, which sounds unsafe to me. Afterall, the original requirement is to probe

Quoted 3 lines

Define unsafe.

If you want security against bad people resuming your machines, please

Yes, this is one of the requirements.

Quoted 4 lines

take a look at existing uswsusp solutions. It defends against that.

If you want security against bad people tampering with your machines physically, sorry, there's no way to defend against that.

No, this is not the requirement.

Quoted 4 lines

But I thought you were trying to do something for secure boot, and "bad person resumes your machine" is out of scope there.

Not exactly, secure boot is one solution to meet the requirement.

Quoted 4 lines

So please always explain security against _what kind of attack_ you are trying to improve; intelligent communication is not possible without that.

User requirement:
A is the user, B is the attacker, user A launches a STD and encrypts A's ram data, then writes these encrypted data onto the disk, so that: Even if user B has access to the disk, B could not know the content of A. Which implies:
1. If B unplugs the disk from A's machine, and plugs the disk onto another machine, B could not decode the content without A's 'permission'.
2. If B is using the same machine as A, even A has walked away leaving the system suspend, B could not resume to A's context without A's 'permission'.

Previously, there are three proposal for this:
a. Enhance the uswsusp(Pavel)
b. Using user provided password to generate the key, for encryption(Yu)

c. Using security boot(TPM or EFI key) for encryption(Joey)

Since I was proposing solution b, I'll say a little more about it. The original idea was that, the user provides a password, then this password is used to generate the key, which means, if user B has provided an incorrect password, the kernel will fail to decrypt the data and is likely to fail the resume process. That is to say, no matter which physical machine B is using, only if he has provided the

password, he would be able to resume. In the first version, the key deviration was firstly done in kernel space, which satisfies the requirement and both saftey. Unfortunately it was rejected and people would like to see the key generated in user space instead. However, using user provided key directly is not safe, according to the discussion in the thread. I don't have good idea on how to improve this, but only have some workarounds, say, ask the kernel to use TPM key to protects the user provided 'key', etc.

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

The whole point of Secure
Boot is a cryptographic system of trust that does not include user space.

I seriously doubt we want to use trusted computing here. So the key needs to be generated in kernel space and stored in a safe manner. As we have a saolution doing that, can we come to ausable synthesis?

Regards
Oliver

Hi Oliver,

Quoted 9 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 5 lines

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

Humm, I did not quite get the point here, let's take fscrypt for example, the kernel gets user generated key from user space, and uses per-inode nonce(random bytes) as the master key to do a KDF(key derivation function) on user provided key, and uses that key for encryption. We can also added similar mechanism to generate the key in kernel space but the key should be original from user's provided key(password derived), because the security boot/signature mechanism could not cover the case that, two different users could resume to each other's context because there isn't any certification during resume if it is on the same physical hardware.

Quoted 11 lines · Yu Chen

Hi Oliver,

Quoted 9 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

As Ard and James's comments, the EFI key can not be accepted:

	https://lkml.org/lkml/2018/8/5/135

The lower entropy problem can be covered by RDRAND or EFI random protocol. But the key point is that we can not fully trust manufacturer. And, the secure boot relies on Microsoft's business interests. It's not designed for confidentiality.

So I will move to TPM trusted key + encrypted key.

Quoted 5 lines

Quoted 5 lines

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

Quoted 12 lines

Humm, I did not quite get the point here, let's take fscrypt for example, the kernel gets user generated key from user space, and uses per-inode nonce(random bytes) as the master key to do a KDF(key derivation function) on user provided key, and uses that key for encryption. We can also added similar mechanism to generate the key in kernel space but the key should be original from user's provided key(password derived), because the security boot/signature mechanism could not cover the case that, two different users could resume to each other's context because there isn't any certification during resume if it is on the same physical hardware.

Sounds there have two different purposes. One is to prevent that the secret in snapshop image be detected/changed outside the machine. Another one try to prevent that B user resumes to A user's context on the same machine.

In the case of B resumes A's context, I still think that the attacker must physical accesses the machine. Which means that it's out of EFI secure boot's design. Could you please explan the detail for the attack?

So I think that the password from user space is for user authentication, and the TPM trusted key is for snapshot image encryption/verification.

Thanks
Joey Lee

Hi Oliver,

Quoted 10 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 4 lines

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

Humm, I did not quite get the point here, let's take fscrypt

for example, the kernel gets user generated key from user space, and uses per-inode nonce(random bytes) as the master key to do a KDF(key derivation function) on user provided key, and uses that key for encryption. We can also added similar mechanism to generate the key in kernel space but the key should be original from user's provided key(password derived), because the security boot/signature mechanism could not cover the case that, two different users could resume to each other's context because there isn't any certification during resume if it is on the same physical hardware.

Quoted 12 lines · Yu Chen

Hi Oliver,

Quoted 10 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 6 lines

Quoted 4 lines

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

Humm, I did not quite get the point here, let's take fscrypt

While the system is running and the fs is mounted, your data is as secure as root access to your machine, right? You encrypt a disk primarily so data cannot be recovered (and altered) while the system is not running.

Secure Boot does not trust root fully. There is a cryptographic chain of trust and user space is not part of it.

Quoted 10 lines

for example, the kernel gets user generated key from user space, and uses per-inode nonce(random bytes) as the master key to do a KDF(key derivation function) on user provided key, and uses that key for encryption. We can also added similar mechanism to generate the key in kernel space but the key should be original from user's provided key(password derived), because the security boot/signature mechanism could not cover the case that, two different users could resume to each other's context because there isn't any certification during resume if it is on the same physical hardware.

Please explain. You will always have to suspend the whole machine with all tasks of all users. And STD with Secure Boot need not imply that you encrypt your discs. You need to encrypt only kernel memory to meet the requirements.

As STD affects the whole machine it must require root rights. So I cannot see how you can talk about a session belonging to a user. Please explain.

It seems to me that you can in theory encrypt the password by a key coming from user space, so that you need to know an additional key to resume the system, but that seems to me above and beyond what Secure Boot requires.

Regards
Oliver

Quoted 25 lines · Oliver Neukum

Quoted 12 lines · Yu Chen

Hi Oliver,

Quoted 10 lines · Oliver Neukum

Quoted 8 lines · Yu Chen

Good point, we once tried to generate key in kernel, but people suggest to generate key in userspace and provide it to the kernel, which is what ecryptfs do currently, so it seems this should also be safe for encryption in kernel.
https://www.spinics.net/lists/linux-crypto/msg33145.html
Thus Chun-Yi's signature can use EFI key and both the key from user space.

Quoted 6 lines

Quoted 4 lines

Hi,

ecryptfs can trust user space. It is supposed to keep data safe while the system is inoperative.

Humm, I did not quite get the point here, let's take fscrypt

While the system is running and the fs is mounted, your data is as secure as root access to your machine, right? You encrypt a disk primarily so data cannot be recovered (and altered) while the system is not running.

Quoted 3 lines

Secure Boot does not trust root fully. There is a cryptographic chain of trust and user space is not part of it.

Okay, I see. So if we want to use secure boot mechanism for hibernation encryption, user space is trusted.

Quoted 4 lines

As STD affects the whole machine it must require root rights. So I cannot see how you can talk about a session belonging to a user. Please explain.

The case is for physical access, not the 'user' in OS.

Quoted 1 line · Pavel Machek

Hi!

Hello,

Quoted 7 lines

Quoted 5 lines

Let me paste the log here:

1. (This is not to compare with uswsusp but other tools) One advantage is: Users do not have to encrypt the whole swap partition as other tools.

Well.. encrypting the partition seems like good idea anyway.

Yes, but it is a policy decision the kernel should not force. STD needs to work anyway.

Quoted 16 lines

Quoted 7 lines

2. Ideally kernel memory should be encrypted by the kernel itself. We have uswsusp to support user space hibernation, however doing the encryption in kernel space has more advantages:
2.1 Not having to transfer plain text kernel memory to
user space. Per Lee, Chun-Yi, uswsusp is disabled when the kernel is locked down:

Quoted 8 lines

https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
linux-fs.git/commit/?h=lockdown-20180410& id=8732c1663d7c0305ae01ba5a1ee4d2299b7b4612 due to:
"There have some functions be locked-down because there have no appropriate mechanisms to check the integrity of writing data."
https://patchwork.kernel.org/patch/10476751/

Quoted 3 lines

So your goal is to make hibernation compatible with kernel lockdown? Do your patches provide sufficient security that hibernation can be enabled with kernel lockdown?

OK, maybe I am dense, but if the key comes from user space, will that be enough?

Quoted 6 lines

Quoted 4 lines

2.2 Not having to copy each page to user space
one by one not in parallel, which might introduce significant amount of copy_to_user() and it might not be efficient on servers having large amount of DRAM.

So how big speedup can be attributed by not doing copy_to_user?

That would be an argument for compression in kernel space. Not encrpting would always be faster.

Quoted 5 lines

Quoted 3 lines

2.3 Distribution has requirement to do snapshot
signature for verification, which can be built by leveraging this patch set.

Signatures can be done by uswsusp, too, right?

Not if you want to keep the chain of trust intact. User space is not signed.

Quoted 9 lines · Yu Chen

Hi,

Quoted 7 lines · Pavel Machek

Quoted 2 lines · Chen Yu

As security becomes more and more important, we add the in-kernel encryption support for hibernation.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Quoted 7 lines

Quoted 5 lines

Which unfortunately means it can not reviewed.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

The advantages are described in detail in
[PATCH 1/4]'s log, please refer to that.

Are you refering to this?

# Generally the advantage is: Users do not have to

# encrypt the whole swap partition as other tools.
# After all, ideally kernel memory should be encrypted
# by the kernel itself.

Sorry, this does not really explain what security benefit it is supposed have to against what attack scenarios.

Note that uswsusp already provides encryption. If this is supposed to have advantages over it, please say so.

Also note that joeyli <[email protected]> has patch series which encrypts both in-kernel and uswsusp hibernation methods. His motivation is secure boot. How does this compare to his work?

This is the core modification to encrypt the hibernation image. It leverages the helper functions to encrypt the page data before they are submitted to the block device. Besides, for the case of hibernation compression, the data are firstly compressed and then encrypted, and vice versa for the resume process.

There is also another solution suggested by Lee, Chun-Yi to re-traverse the snapshot image at one time and write them either to disk or exposed to user space. In that way if the snapshot image can be encrypted and authentication, then the uswsusp interface is available for userspace, kernel does not need to lock it down. The only disadvantages are re-traversing large number of pages in snapshot might bring overhead and makes snapshot logic a little coupling with crypto logic.

Suggested-by Rafael J. Wysocki <[email protected]>

Cc Rafael J. Wysocki <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Len Brown <[email protected]>

Cc "Lee, Chun-Yi" <[email protected]>

Cc Eric Biggers <[email protected]>

Cc "Theodore Ts'o" <[email protected]>

Cc Stephan Mueller <[email protected]>

Cc Denis Kenzior <[email protected]>

Cc [email protected]

Signed-off-by Chen Yu <[email protected]>

---
 kernel/power/power.h |  23 +++++++
 kernel/power/swap.c  | 182 ++++++++++++++++++++++++++++++++++++++++++++++++---
 2 files changed, 197 insertions(+), 8 deletions(-)

kernel/power/power.h +23 -0

index ba3b24c..b8ddc05 100644
@@ -109,8 +109,30 @@ struct hibernation_crypto {
 
 extern void hibernation_set_crypto_ops(
 	const struct hibernation_crypto_ops *ops);
+
+/**
+ * get_crypto_cmd - Get the crypto command.
+ * @suspend: In suspend.
+ * @last_page: If this is the last page. For signature's
+ * 	       hash update/final checking.
+ */
+static inline unsigned int get_crypto_cmd(bool suspend,
+		bool last_page)
+{
+	/* TODO: signature support */
+	if (suspend) {
+		return CMD_ENCRYPT;
+	} else {
+		return CMD_DECRYPT;
+	}
+}
 #else
 #define HIBERNATE_MAX_SALT_BYTES	0
+static inline unsigned int get_crypto_cmd(bool suspend,
+		bool last_page)
+{
+	return -EINVAL;
+}
 #endif
 
 #else /* !CONFIG_HIBERNATION */

@@ -214,6 +236,7 @@ extern int swsusp_swap_in_use(void);
 #define SF_PLATFORM_MODE	1
 #define SF_NOCOMPRESS_MODE	2
 #define SF_CRC32_MODE	        4
+#define SF_CRYPTO_MODE		8
 
 /* kernel/power/hibernate.c */
 extern int swsusp_check(void);

kernel/power/swap.c +174 -8

index c2bcf97..4b36fb7 100644
@@ -102,14 +102,16 @@ struct swap_map_handle {
 	unsigned int k;
 	unsigned long reqd_free_pages;
 	u32 crc32;
+	bool crypto;
 };
 
 struct swsusp_header {
 	char reserved[PAGE_SIZE - 20 - sizeof(sector_t) - sizeof(int) -
-	              sizeof(u32)];
+			sizeof(u32) - HIBERNATE_MAX_SALT_BYTES];
 	u32	crc32;
 	sector_t image;
 	unsigned int flags;	/* Flags to pass to the "boot" kernel */
+	char salt[HIBERNATE_MAX_SALT_BYTES];
 	char	orig_sig[10];
 	char	sig[10];
 } __packed;

@@ -318,6 +320,10 @@ static int mark_swapfiles(struct swap_map_handle *handle, unsigned int flags)
 		swsusp_header->flags = flags;
 		if (flags & SF_CRC32_MODE)
 			swsusp_header->crc32 = handle->crc32;
+		if (handle->crypto) {
+			swsusp_header->flags |= SF_CRYPTO_MODE;
+			hibernation_crypto_save((void *)swsusp_header->salt);
+		}
 		error = hib_submit_io(REQ_OP_WRITE, REQ_SYNC,
 				      swsusp_resume_block, swsusp_header, NULL);
 	} else {

@@ -536,10 +542,12 @@ static int save_image(struct swap_map_handle *handle,
 	unsigned int m;
 	int ret;
 	int nr_pages;
+	int crypto_page_idx;
 	int err2;
 	struct hib_bio_batch hb;
 	ktime_t start;
 	ktime_t stop;
+	void *tmp = NULL, *crypt_buf = NULL;
 
 	hib_init_batch(&hb);
 

@@ -549,12 +557,36 @@ static int save_image(struct swap_map_handle *handle,
 	if (!m)
 		m = 1;
 	nr_pages = 0;
+	crypto_page_idx = 0;
+	/* Allocate temporary buffer for crypto. */
+	if (handle->crypto) {
+		crypt_buf = (void *)get_zeroed_page(GFP_KERNEL);
+		if (!crypt_buf)
+			return -ENOMEM;
+	}
+
 	start = ktime_get();
 	while (1) {
 		ret = snapshot_read_next(snapshot);
 		if (ret <= 0)
 			break;
-		ret = swap_write_page(handle, data_of(*snapshot), &hb);
+		tmp = data_of(*snapshot);
+		if (handle->crypto) {
+			/* Encryption before submit_io.*/
+			ret = hibernation_crypto_data(data_of(*snapshot),
+				PAGE_SIZE,
+				crypt_buf,
+				PAGE_SIZE,
+				get_crypto_cmd(true,
+				 (crypto_page_idx ==
+				  (nr_to_write - 1))),
+				crypto_page_idx);
+			if (ret)
+				goto out;
+			crypto_page_idx++;
+			tmp = crypt_buf;
+		}
+		ret = swap_write_page(handle, tmp, &hb);
 		if (ret)
 			break;
 		if (!(nr_pages % m))

@@ -569,6 +601,9 @@ static int save_image(struct swap_map_handle *handle,
 	if (!ret)
 		pr_info("Image saving done\n");
 	swsusp_show_speed(start, stop, nr_to_write, "Wrote");
+ out:
+	if (crypt_buf)
+		free_page((unsigned long)crypt_buf);
 	return ret;
 }
 

@@ -672,6 +707,7 @@ static int save_image_lzo(struct swap_map_handle *handle,
 	unsigned int m;
 	int ret = 0;
 	int nr_pages;
+	int crypto_page_idx;
 	int err2;
 	struct hib_bio_batch hb;
 	ktime_t start;

@@ -767,6 +803,7 @@ static int save_image_lzo(struct swap_map_handle *handle,
 	if (!m)
 		m = 1;
 	nr_pages = 0;
+	crypto_page_idx = 0;
 	start = ktime_get();
 	for (;;) {
 		for (thr = 0; thr < nr_threads; thr++) {

@@ -835,7 +872,28 @@ static int save_image_lzo(struct swap_map_handle *handle,
 			for (off = 0;
 			     off < LZO_HEADER + data[thr].cmp_len;
 			     off += PAGE_SIZE) {
-				memcpy(page, data[thr].cmp + off, PAGE_SIZE);
+				if (handle->crypto) {
+					/*
+					 * Encrypt the compressed data
+					 * before we write them to the
+					 * block device.
+					 */
+					ret = hibernation_crypto_data(
+							data[thr].cmp + off,
+							PAGE_SIZE,
+							page,
+							PAGE_SIZE,
+							get_crypto_cmd(true,
+							 (crypto_page_idx ==
+							 (nr_to_write - 1))),
+							crypto_page_idx);
+					if (ret)
+						goto out_finish;
+					crypto_page_idx++;
+				} else {
+					memcpy(page, data[thr].cmp + off,
+						PAGE_SIZE);
+				}
 
 				ret = swap_write_page(handle, page, &hb);
 				if (ret)

@@ -909,6 +967,7 @@ int swsusp_write(unsigned int flags)
 	int error;
 
 	pages = snapshot_get_image_size();
+	memset(&handle, 0, sizeof(struct swap_map_handle));
 	error = get_swap_writer(&handle);
 	if (error) {
 		pr_err("Cannot get swap writer\n");

@@ -922,6 +981,9 @@ int swsusp_write(unsigned int flags)
 		}
 	}
 	memset(&snapshot, 0, sizeof(struct snapshot_handle));
+	if (!hibernation_crypto_init(true))
+		/* The image needs to be encrypted or signature. */
+		handle.crypto = true;
 	error = snapshot_read_next(&snapshot);
 	if (error < PAGE_SIZE) {
 		if (error >= 0)

@@ -1060,6 +1122,8 @@ static int load_image(struct swap_map_handle *handle,
 	struct hib_bio_batch hb;
 	int err2;
 	unsigned nr_pages;
+	unsigned int crypto_page_idx;
+	void *crypt_buf = NULL;
 
 	hib_init_batch(&hb);
 

@@ -1069,18 +1133,46 @@ static int load_image(struct swap_map_handle *handle,
 	if (!m)
 		m = 1;
 	nr_pages = 0;
+	crypto_page_idx = 0;
+	/* Allocate temporary buffer for crypto. */
+	if (handle->crypto) {
+		crypt_buf = (void *)get_zeroed_page(GFP_KERNEL);
+		if (!crypt_buf)
+			return -ENOMEM;
+	}
 	start = ktime_get();
 	for ( ; ; ) {
 		ret = snapshot_write_next(snapshot);
 		if (ret <= 0)
 			break;
-		ret = swap_read_page(handle, data_of(*snapshot), &hb);
+		if (handle->crypto)
+			ret = swap_read_page(handle, crypt_buf, &hb);
+		else
+			ret = swap_read_page(handle, data_of(*snapshot), &hb);
 		if (ret)
 			break;
-		if (snapshot->sync_read)
+		/* If encryption is enabled, disable async io. */
+		if (handle->crypto || snapshot->sync_read)
 			ret = hib_wait_io(&hb);
 		if (ret)
 			break;
+		if (handle->crypto) {
+			/*
+			 * Need a decryption for the
+			 * data read from the block
+			 * device.
+			 */
+			ret = hibernation_crypto_data(crypt_buf, PAGE_SIZE,
+					  data_of(*snapshot),
+					  PAGE_SIZE,
+					  get_crypto_cmd(false,
+					   (crypto_page_idx ==
+					   (nr_to_read - 1))),
+					  crypto_page_idx);
+			if (ret)
+				break;
+			crypto_page_idx++;
+		}
 		if (!(nr_pages % m))
 			pr_info("Image loading progress: %3d%%\n",
 				nr_pages / m * 10);

@@ -1097,6 +1189,8 @@ static int load_image(struct swap_map_handle *handle,
 			ret = -ENODATA;
 	}
 	swsusp_show_speed(start, stop, nr_to_read, "Read");
+	if (crypt_buf)
+		free_page((unsigned long)crypt_buf);
 	return ret;
 }
 

@@ -1165,6 +1259,7 @@ static int load_image_lzo(struct swap_map_handle *handle,
 	ktime_t start;
 	ktime_t stop;
 	unsigned nr_pages;
+	unsigned int crypto_page_idx;
 	size_t off;
 	unsigned i, thr, run_threads, nr_threads;
 	unsigned ring = 0, pg = 0, ring_size = 0,

@@ -1173,6 +1268,7 @@ static int load_image_lzo(struct swap_map_handle *handle,
 	unsigned char **page = NULL;
 	struct dec_data *data = NULL;
 	struct crc_data *crc = NULL;
+	void *first_page = NULL;
 
 	hib_init_batch(&hb);
 

@@ -1278,6 +1374,18 @@ static int load_image_lzo(struct swap_map_handle *handle,
 	}
 	want = ring_size = i;
 
+	/*
+	 * The first page of data[thr] contains the length of
+	 * compressed data, this page should not mess up the
+	 * read buffer, so we allocate a separate page for it.
+	 */
+	if (handle->crypto) {
+		first_page = (void *)get_zeroed_page(GFP_KERNEL);
+		if (!first_page) {
+			ret = -ENOMEM;
+			goto out_clean;
+		}
+	}
 	pr_info("Using %u thread(s) for decompression\n", nr_threads);
 	pr_info("Loading and decompressing image data (%u pages)...\n",
 		nr_to_read);

@@ -1285,6 +1393,7 @@ static int load_image_lzo(struct swap_map_handle *handle,
 	if (!m)
 		m = 1;
 	nr_pages = 0;
+	crypto_page_idx = 0;
 	start = ktime_get();
 
 	ret = snapshot_write_next(snapshot);

@@ -1336,7 +1445,26 @@ static int load_image_lzo(struct swap_map_handle *handle,
 		}
 
 		for (thr = 0; have && thr < nr_threads; thr++) {
-			data[thr].cmp_len = *(size_t *)page[pg];
+			if (handle->crypto) {
+				/*
+				 * Need to decrypt the first page
+				 * of each data[thr], which contains
+				 * the compressed data length.
+				 */
+				ret = hibernation_crypto_data(page[pg],
+						  PAGE_SIZE,
+						  first_page,
+						  PAGE_SIZE,
+						  get_crypto_cmd(false,
+						   (crypto_page_idx ==
+						   (nr_to_read - 1))),
+						  crypto_page_idx);
+				if (ret)
+					goto out_finish;
+				data[thr].cmp_len = *(size_t *)first_page;
+			} else {
+				data[thr].cmp_len = *(size_t *)page[pg];
+			}
 			if (unlikely(!data[thr].cmp_len ||
 			             data[thr].cmp_len >
 			             lzo1x_worst_compress(LZO_UNC_SIZE))) {

@@ -1358,8 +1486,29 @@ static int load_image_lzo(struct swap_map_handle *handle,
 			for (off = 0;
 			     off < LZO_HEADER + data[thr].cmp_len;
 			     off += PAGE_SIZE) {
-				memcpy(data[thr].cmp + off,
-				       page[pg], PAGE_SIZE);
+				if (handle->crypto) {
+					/*
+					 * Decrypt the compressed data
+					 * and leverage the decompression
+					 * threads to get it done.
+					 */
+					ret = hibernation_crypto_data(
+							page[pg],
+							PAGE_SIZE,
+							data[thr].cmp + off,
+							PAGE_SIZE,
+							get_crypto_cmd(false,
+							 (crypto_page_idx ==
+							 (nr_to_read - 1))),
+							crypto_page_idx);
+					if (ret)
+						goto out_finish;
+					crypto_page_idx++;
+				} else {
+					memcpy(data[thr].cmp + off,
+						page[pg], PAGE_SIZE);
+
+				}
 				have--;
 				want++;
 				if (++pg >= ring_size)

@@ -1452,6 +1601,8 @@ static int load_image_lzo(struct swap_map_handle *handle,
 out_clean:
 	for (i = 0; i < ring_size; i++)
 		free_page((unsigned long)page[i]);
+	if (first_page)
+		free_page((unsigned long)first_page);
 	if (crc) {
 		if (crc->thr)
 			kthread_stop(crc->thr);

@@ -1482,6 +1633,7 @@ int swsusp_read(unsigned int *flags_p)
 	struct swsusp_info *header;
 
 	memset(&snapshot, 0, sizeof(struct snapshot_handle));
+	memset(&handle, 0, sizeof(struct swap_map_handle));
 	error = snapshot_write_next(&snapshot);
 	if (error < PAGE_SIZE)
 		return error < 0 ? error : -EFAULT;

@@ -1489,6 +1641,16 @@ int swsusp_read(unsigned int *flags_p)
 	error = get_swap_reader(&handle, flags_p);
 	if (error)
 		goto end;
+	if (*flags_p & SF_CRYPTO_MODE) {
+		error = hibernation_crypto_init(false);
+		if (!error) {
+			/* The image has been encrypted. */
+			handle.crypto = true;
+		} else {
+			pr_err("Failed to init cipher during resume.\n");
+			goto end;
+		}
+	}
 	if (!error)
 		error = swap_read_page(&handle, header, NULL);
 	if (!error) {

@@ -1526,6 +1688,10 @@ int swsusp_check(void)
 
 		if (!memcmp(HIBERNATE_SIG, swsusp_header->sig, 10)) {
 			memcpy(swsusp_header->sig, swsusp_header->orig_sig, 10);
+			/* Read salt passed from previous kernel. */
+			if (swsusp_header->flags & SF_CRYPTO_MODE)
+				hibernation_crypto_restore(
+						(void *)&swsusp_header->salt);
 			/* Reset swap signature now */
 			error = hib_submit_io(REQ_OP_WRITE, REQ_SYNC,
 						swsusp_resume_block,

Signature · 1 line

2.7.4