-
Notifications
You must be signed in to change notification settings - Fork 33
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.
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
[RFE] Restricting access to physical memory #1158
Comments
Have you looked into kernel lockdown (https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)? That has a confidentiality mode that you can enable and then
We generally tend to not carry out of tree patches that change behavior from upstream.
As someone working on "confidential containers" I would say: if you want full confidentiality you need to run your containers with something like Kata containers and using confidential computing hardware to get the guarantees you mention. |
Is "confidential computing hardware" provided by CPUs with TPM 1.x or TPM 2? Or is there more to it? Going to learn more about Kata now Thanks! |
No - TPM is not enough. This is about technologies such as AMD SEV-SNP or Intel TDX. |
Current situation
The kernel has CONFIG_PROC_KCORE enabled so that all physical memory can be examined
Impact
If sensitive data or keys to run an encrypted container are used they will be present in memory allowing anyone with access to the to capture the keys
Ideal future situation
Can flatcar run with /pro/kcore disabled? Also it might be valuable to disable /proc/[pid]/mem which also provides access to a single process's memory (kernel patch needed)
Implementation options
Also would insure CONFIG_CROSS_MEMORY_ATTACH=n as well as CONFIG_STRICT_DEVMEM=y and maybe some others
Additional information
Why am I asking? All existing system assume every user trusts the root user when in fact we often don't know them.
Closing direct memory access eliminates the need to trust them.
They can kill the system but that is very different from compromising sensitive data
The text was updated successfully, but these errors were encountered: