[PATCH] proc/kcore: Allow disabling /proc/kcore at boot

[PATCH] proc/kcore: Allow disabling /proc/kcore at boot

[Chris Down]

/proc/kcore lets any process with CAP_SYS_RAWIO read all of kernel
memory. That's a pretty large read primitive for anyone who obtains
CAP_SYS_RAWIO (and it also gives away the KASLR layout).

For this reason on some hosts we want to turn /proc/kcore off. However,
on a kernel built with CONFIG_PROC_KCORE=y the only ways to block it
today are lockdown=confidentiality (which also disables many other
things we perhaps don't want to disable), or LSM. That's annoying,
because on the majority of hosts we do want it on for things like
drgn/crash, so today we build two separate kernels.

Let's add a "kcore=" boot parameter so that this can be disabled at
boot.

Signed-off-by: Chris Down <chris@chrisdown.name>
---
 Documentation/admin-guide/kernel-parameters.txt |  6 ++++++
 fs/proc/kcore.c                                 | 12 ++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index e75344f4e0cd..d8acce2878ab 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2915,6 +2915,12 @@ Kernel parameters
 			parameter KASAN will print report only for the first
 			invalid access.
 
+	kcore=		[KNL,EARLY]
+			Enable or disable /proc/kcore on kernels built with
+			CONFIG_PROC_KCORE=y.
+			Format: <bool>
+			Default: on
+
 	keep_bootcon	[KNL,EARLY]
 			Do not unregister boot console at start. This is only
 			useful for debugging when something happens in the window
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index 390547b992ac..6a29a3e0ed92 100644
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@ -69,6 +69,7 @@ static size_t kcore_notes_len;
 static size_t kcore_data_offset;
 DEFINE_STATIC_PERCPU_RWSEM(kclist_lock);
 static int kcore_need_update = 1;
+static bool kcore_enabled __initdata = true;
 
 /*
  * Returns > 0 for RAM pages, 0 for non-RAM pages, < 0 on error
@@ -720,8 +721,19 @@ static void __init add_modules_range(void)
 }
 #endif
 
+static int __init parse_kcore(char *str)
+{
+	return kstrtobool(str, &kcore_enabled);
+}
+early_param("kcore", parse_kcore);
+
 static int __init proc_kcore_init(void)
 {
+	if (!kcore_enabled) {
+		pr_info("/proc/kcore disabled on command line\n");
+		return 0;
+	}
+
 	proc_root_kcore = proc_create("kcore", S_IRUSR, NULL, &kcore_proc_ops);
 	if (!proc_root_kcore) {
 		pr_err("couldn't create /proc/kcore\n");

base-commit: 01146870c415f6ff70a469fb7ceb962a3f2c8c52
-- 
2.54.0

Re: [PATCH] proc/kcore: Allow disabling /proc/kcore at boot

[Omar Sandoval]

On Tue, Oct 27, 2026 at 12:21:14PM +0800, Chris Down wrote:
> /proc/kcore lets any process with CAP_SYS_RAWIO read all of kernel
> memory. That's a pretty large read primitive for anyone who obtains
> CAP_SYS_RAWIO (and it also gives away the KASLR layout).
> 
> For this reason on some hosts we want to turn /proc/kcore off. However,
> on a kernel built with CONFIG_PROC_KCORE=y the only ways to block it
> today are lockdown=confidentiality (which also disables many other
> things we perhaps don't want to disable), or LSM. That's annoying,
> because on the majority of hosts we do want it on for things like
> drgn/crash, so today we build two separate kernels.
> 
> Let's add a "kcore=" boot parameter so that this can be disabled at
> boot.
> 
> Signed-off-by: Chris Down <chris@chrisdown.name>

Hey, Chris,

The code looks correct, but is there a reason that /proc/kcore
(CAP_SYS_RAWIO) is any more concerning than other ways to read kernel
memory (e.g., CAP_BPF + CAP_PERFMON)?

Thanks,
Omar

Re: [PATCH] proc/kcore: Allow disabling /proc/kcore at boot

[Chris Down]

Hi Omar,

Thanks for taking a look!

Omar Sandoval writes:
>The code looks correct, but is there a reason that /proc/kcore
>(CAP_SYS_RAWIO) is any more concerning than other ways to read kernel
>memory (e.g., CAP_BPF + CAP_PERFMON)?

Not in terms of what it can read, indeed. I would say the distinction is more 
about who needs each capability and what we can remove.

Abstractly speaking CAP_SYS_RAWIO may be needed for hardware access without 
necessarily wanting to grant general RAM access. STRICT_DEVMEM already makes 
that possible for /dev/mem, but /proc/kcore gives the same capability to do 
general purpose RAM reading anyway.

In our case in particular, a process with CAP_SYS_RAWIO doesn't necessarily 
have CAP_BPF and CAP_PERFMON, so keeping BPF available doesn't make removing 
kcore redundant.  On the hosts in question, BPF tracing and BPF LSM are part of 
the monitoring and sandboxing we rely on, so we can't remove it from the kernel 
entirely, but we nevertheless keep CAP_BPF and CAP_PERFMON away from guest 
facing processes. Nothing on those host uses /proc/kcore, so we remove it as 
one more gap to close.

For that reason those hosts already run with CONFIG_PROC_KCORE=n, while other 
hosts keep kcore to aid debugging, since they have a different threat model.  
This patch, then, lets us preserve those choices while using the same kernel 
image.

In retrospect I should have explained that better in the commit message :-) I 
can update it for v2. Does that make more sense? Let me know if I can clarify 
further.

Thanks!