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

[Omar Sandoval]

On Fri, Oct 30, 2026 at 01:38:13AM +0800, Chris Down wrote:
> 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!

Yeah, with a bit more justification in the commit message I'm fine with
this.

Thanks,
Omar