diff mbox series

[ebpf,v2,2/2] bpf: Make unprivileged bpf depend on CONFIG_CPU_SPECTRE

Message ID 882f5c31f48bac75ebaede2a0ec321ec67128229.1635383031.git.pawan.kumar.gupta@linux.intel.com (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series Unprivileged BPF default | expand

Checks

Context Check Description
bpf/vmtest-bpf-next success VM_Test
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf success VM_Test
bpf/vmtest-bpf-PR success PR summary

Commit Message

Pawan Gupta Oct. 28, 2021, 1:35 a.m. UTC
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@linux.intel.com>

[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(+)

Comments

Greg KH Oct. 28, 2021, 5:34 a.m. UTC | #1
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@linux.intel.com>
> 
> [1] https://ebpf.io/summit-2021-slides/eBPF_Summit_2021-Keynote-Daniel_Borkmann-BPF_and_Spectre.pdf

This should go above the signed-off-by line, in the changelog text, not
below it, otherwise our tools get confused when trying to apply it.

thanks,

greg k-h
Mark Rutland Oct. 28, 2021, 1:57 p.m. UTC | #2
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@linux.intel.com>
> 
> [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"?

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.

Thanks,
Mark.

>  	depends on BPF_SYSCALL
>  	help
>  	  Disables unprivileged BPF by default by setting the corresponding
> @@ -72,6 +73,10 @@ config BPF_UNPRIV_DEFAULT_OFF
>  	  disable it by setting it to 1 (from which no other transition to
>  	  0 is possible anymore).
>  
> +	  Unprivileged BPF can be used to exploit potential speculative
> +	  execution side-channel vulnerabilities on affected hardware. If you
> +	  are concerned about it, answer Y.
> +
>  source "kernel/bpf/preload/Kconfig"
>  
>  config BPF_LSM
> -- 
> 2.31.1
>
Greg KH Oct. 28, 2021, 4:44 p.m. UTC | #3
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@linux.intel.com>
> > 
> > [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
Pawan Gupta Oct. 28, 2021, 7:38 p.m. UTC | #4
On 28.10.2021 07:34, Greg KH 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@linux.intel.com>
>>
>> [1] https://ebpf.io/summit-2021-slides/eBPF_Summit_2021-Keynote-Daniel_Borkmann-BPF_and_Spectre.pdf
>
>This should go above the signed-off-by line, in the changelog text, not
>below it, otherwise our tools get confused when trying to apply it.

Thanks, I will fix it.
diff mbox series

Patch

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
 	depends on BPF_SYSCALL
 	help
 	  Disables unprivileged BPF by default by setting the corresponding
@@ -72,6 +73,10 @@  config BPF_UNPRIV_DEFAULT_OFF
 	  disable it by setting it to 1 (from which no other transition to
 	  0 is possible anymore).
 
+	  Unprivileged BPF can be used to exploit potential speculative
+	  execution side-channel vulnerabilities on affected hardware. If you
+	  are concerned about it, answer Y.
+
 source "kernel/bpf/preload/Kconfig"
 
 config BPF_LSM