On Thu, Oct 28, 2021 at 02:57:51PM +0100, Mark Rutland wrote: > On Wed, Oct 27, 2021 at 06:35:44PM -0700, Pawan Gupta wrote: > > Disabling unprivileged BPF would help prevent unprivileged users from > > creating the conditions required for potential speculative execution > > side-channel attacks on affected hardware. A deep dive on such attacks > > and mitigation is available here [1]. > > > > If an architecture selects CONFIG_CPU_SPECTRE, disable unprivileged BPF > > by default. An admin can enable this at runtime, if necessary. > > > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx> > > > > [1] https://ebpf.io/summit-2021-slides/eBPF_Summit_2021-Keynote-Daniel_Borkmann-BPF_and_Spectre.pdf > > --- > > kernel/bpf/Kconfig | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig > > index a82d6de86522..510a5a73f9a2 100644 > > --- a/kernel/bpf/Kconfig > > +++ b/kernel/bpf/Kconfig > > @@ -64,6 +64,7 @@ config BPF_JIT_DEFAULT_ON > > > > config BPF_UNPRIV_DEFAULT_OFF > > bool "Disable unprivileged BPF by default" > > + default y if CPU_SPECTRE > > Why can't this just be "default y"? Because not all arches are broken. > This series makes that the case on x86, and if SW is going to have to > deal with that we may as well do that everywhere, and say that on all > architectures we leave it to the sysadmin or kernel builder to optin to > permitting unprivileged BPF. > > If we can change the default for x86 I see no reason we can't change > this globally, and we avoid tying this to CPU_SPECTRE specifically. No, this is a spectre-like issue only, if you have hardware that does not have these types of issues, why wouldn't this be ok to be disabled? thanks, greg k-h
