Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add CONFIG_AMD_MEM_ENCRYPT #132

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add CONFIG_AMD_MEM_ENCRYPT #132

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions kernel_hardening_checker/checks.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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')]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, anti-forensic is not really an exploit class/technique, but I think it still falls within the scope of hardening, no?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

if arch == 'ARM64':
l += [KconfigCheck('self_protection', 'kspp', 'ARM64_SW_TTBR0_PAN', 'y')]
l += [KconfigCheck('self_protection', 'kspp', 'SHADOW_CALL_STACK', 'y')]
Expand Down