Add CONFIG_AMD_MEM_ENCRYPT #132
Conversation
Encrypted RAM is a security mechanism, if only against forensic.
a13xp0p0v
force-pushed
the
master
branch
2 times, most recently
from
ea24300
to
78f5595
Compare
| @@ -238,6 +238,7 @@ def add_kconfig_checks(l, arch): | |||
| iommu_support_is_set)] | |||
| l += [AND(KconfigCheck('self_protection', 'kspp', 'AMD_IOMMU_V2', 'y'), | |||
| iommu_support_is_set)] | |||
| l += [KconfigCheck('self_protection', 'defconfig', 'AMD_MEM_ENCRYPT', 'y')] | |||
There was a problem hiding this comment.
Hi @jvoisin,
The AMD_MEM_ENCRYPT kconfig option is not enabled by default.
Hence we can't write this as "defconfig recommendation".
I also can't call it self_protection because it doesn't mitigate any kernel vulnerability class or exploit technique.
So for now this check doesn't look very convincing for me.
There was a problem hiding this comment.
Yeah, anti-forensic is not really an exploit class/technique, but I think it still falls within the scope of hardening, no?
There was a problem hiding this comment.
I don't have a strong opinion on it.
Maybe the reason of this check can be changed to something like confidential computing instead of self_protection: https://aws.amazon.com/blogs/security/confidential-computing-an-aws-perspective/
But honestly, I'm not very optimistic about confidential computing because of side channels like this:
https://cipherleaks.com/
We need to discuss it more with KSPP and friends before recommending to users.
There was a problem hiding this comment.
I think the threat model is more about preventing data from being recovered from the ram after an abrupt poweroff than about protecting data at runtime.
a13xp0p0v
added
the
idea_for_the_future
Encrypted RAM is a security mechanism, if only against forensic.