[PATCH ebpf v2 0/2] Unprivileged BPF default

[PATCH ebpf v2 0/2] Unprivileged BPF default

[Pawan Gupta]

Hi,

This is a two patch series to make the compile time default of
unprivileged BPF depend on CONFIG_CPU_SPECTRE. First patch makes ARM's
CONFIG_CPU_SPECTRE available for all architectures. The second patch
sets CONFIG_BPF_UNPRIV_DEFAULT_OFF=y by default when
CONFIG_CPU_SPECTRE=y.

v2:
- Generalize ARM's CONFIG_CPU_SPECTRE to be available for all architectures.
- Make CONFIG_BPF_UNPRIV_DEFAULT_OFF depend on CONFIG_CPU_SPECTRE.
- Updated commit message to reflect the dependency on CONFIG_CPU_SPECTRE.
- Add reference to BPF spectre presentation in commit message.

v1: https://lore.kernel.org/all/d37b01e70e65dced2659561ed5bc4b2ed1a50711.1635367330.git.pawan.kumar.gupta@linux.intel.com/

Pawan Gupta (2):
  arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures
  bpf: Make unprivileged bpf depend on CONFIG_CPU_SPECTRE

 arch/Kconfig        | 3 +++
 arch/arm/mm/Kconfig | 3 ---
 arch/x86/Kconfig    | 1 +
 kernel/bpf/Kconfig  | 5 +++++
 4 files changed, 9 insertions(+), 3 deletions(-)

-- 
2.31.1

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

[Pawan Gupta]

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
 	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

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

[Greg KH]

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

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

[Pawan Gupta]

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.

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

[Mark Rutland]

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
> 

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

[Greg KH]

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

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Pawan Gupta]

On 28.10.2021 14:49, Mark Rutland wrote:
>On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote:
>> Borrow CONFIG_CPU_SPECTRE from ARM to be available for all
>> architectures. This will help in configuration of features that depend
>> on CPU being affected by spectre class of vulnerabilities.
>>
>> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>
>Given that spectre isn't one specific issue, biut rather a blanket term
>for a bunch of things that can have variable overlap, I don't think this
>makes much sense unless we're going to add finer-grained options for all
>the variants, and IMO it'd make more sene for the architectures to
>directly select the things that'd otherwise be dependent on this.

Isn't ARM already using CPU_SPECTRE for selecting things: 

	config HARDEN_BRANCH_PREDICTOR
	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
	     depends on CPU_SPECTRE

This was the whole motivation for doing the same for x86.

Adding a condition for all architectures is also okay, but its going to
a little messier:

	 config BPF_UNPRIV_DEFAULT_OFF
	        default y if X86 || ARM || ... 

This approach would make sense if architectures wants to explicitly
select the defaults irrespective of architecture being affected by
spectre.

If that's the case I will change the BPF_UNPRIV_DEFAULT_OFF default to
depend on architecture. I hope BPF maintainer, Daniel is okay with it?

Pawan

Added BPF maintainers and bpf@vger to cc.

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Mark Rutland]

On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
> On 28.10.2021 14:49, Mark Rutland wrote:
> > On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote:
> > > Borrow CONFIG_CPU_SPECTRE from ARM to be available for all
> > > architectures. This will help in configuration of features that depend
> > > on CPU being affected by spectre class of vulnerabilities.
> > > 
> > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > 
> > Given that spectre isn't one specific issue, biut rather a blanket term
> > for a bunch of things that can have variable overlap, I don't think this
> > makes much sense unless we're going to add finer-grained options for all
> > the variants, and IMO it'd make more sene for the architectures to
> > directly select the things that'd otherwise be dependent on this.
> 
> Isn't ARM already using CPU_SPECTRE for selecting things:
> 
> 	config HARDEN_BRANCH_PREDICTOR
> 	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
> 	     depends on CPU_SPECTRE

It's true that arch/arm does, but that's not true for other
architectures, e.g. powerpc or arm64, and and as above I don't think it
makes sense to make this generic in its current form because "spectre"
is a somewhat vague generic term.

> This was the whole motivation for doing the same for x86.
> 
> Adding a condition for all architectures is also okay, but its going to
> a little messier:
> 
> 	 config BPF_UNPRIV_DEFAULT_OFF
> 	        default y if X86 || ARM || ...
> 
> This approach would make sense if architectures wants to explicitly
> select the defaults irrespective of architecture being affected by
> spectre.

If we're going to change the default for some architectures, I think
it'd make much more sense to just do that for all, without any
arch-specific conditionality, i.e.

	config BPF_UNPRIV_DEFAULT_OFF
		default y

... so that the behaviour is consistent across all architectures, and we
don't have to play a whack-a-mole game as/when we realise architectures
are affected by some variant of an issue relating to speculation.

Thanks,
Mark.

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Daniel Borkmann]

On 10/29/21 11:22 AM, Mark Rutland wrote:
> On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
>> On 28.10.2021 14:49, Mark Rutland wrote:
>>> On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote:
>>>> Borrow CONFIG_CPU_SPECTRE from ARM to be available for all
>>>> architectures. This will help in configuration of features that depend
>>>> on CPU being affected by spectre class of vulnerabilities.
>>>>
>>>> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>>>
>>> Given that spectre isn't one specific issue, biut rather a blanket term
>>> for a bunch of things that can have variable overlap, I don't think this
>>> makes much sense unless we're going to add finer-grained options for all
>>> the variants, and IMO it'd make more sene for the architectures to
>>> directly select the things that'd otherwise be dependent on this.
>>
>> Isn't ARM already using CPU_SPECTRE for selecting things:
>>
>> 	config HARDEN_BRANCH_PREDICTOR
>> 	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
>> 	     depends on CPU_SPECTRE
> 
> It's true that arch/arm does, but that's not true for other
> architectures, e.g. powerpc or arm64, and and as above I don't think it
> makes sense to make this generic in its current form because "spectre"
> is a somewhat vague generic term.
> 
>> This was the whole motivation for doing the same for x86.
>>
>> Adding a condition for all architectures is also okay, but its going to
>> a little messier:
>>
>> 	 config BPF_UNPRIV_DEFAULT_OFF
>> 	        default y if X86 || ARM || ...
>>
>> This approach would make sense if architectures wants to explicitly
>> select the defaults irrespective of architecture being affected by
>> spectre.
> 
> If we're going to change the default for some architectures, I think
> it'd make much more sense to just do that for all, without any
> arch-specific conditionality, i.e.
> 
> 	config BPF_UNPRIV_DEFAULT_OFF
> 		default y

Lets just go with 'default y'. The main rationale for this change was motivated
by spectre, so would have been good to indicate this also with an explicit
dependency for broken HW, not just help description. Pretty much agreeing with
Greg here [0]. Eventually, we might need some arch generic way to determine arch-
common spectre type bugs, so that for unaffected HW we don't need to apply some
of them from verifier, but that's still tbd.

Thanks,
Daniel

   [0] https://lore.kernel.org/bpf/YXrTev6WMXry9pFI@kroah.com/

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Pawan Gupta]

On 29.10.2021 18:05, Daniel Borkmann wrote:
>On 10/29/21 11:22 AM, Mark Rutland wrote:
>>On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
>>>On 28.10.2021 14:49, Mark Rutland wrote:
>>>>On Wed, Oct 27, 2021 at 06:33:22PM -0700, Pawan Gupta wrote:
>>>>>Borrow CONFIG_CPU_SPECTRE from ARM to be available for all
>>>>>architectures. This will help in configuration of features that depend
>>>>>on CPU being affected by spectre class of vulnerabilities.
>>>>>
>>>>>Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
>>>>
>>>>Given that spectre isn't one specific issue, biut rather a blanket term
>>>>for a bunch of things that can have variable overlap, I don't think this
>>>>makes much sense unless we're going to add finer-grained options for all
>>>>the variants, and IMO it'd make more sene for the architectures to
>>>>directly select the things that'd otherwise be dependent on this.
>>>
>>>Isn't ARM already using CPU_SPECTRE for selecting things:
>>>
>>>	config HARDEN_BRANCH_PREDICTOR
>>>	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
>>>	     depends on CPU_SPECTRE
>>
>>It's true that arch/arm does, but that's not true for other
>>architectures, e.g. powerpc or arm64, and and as above I don't think it
>>makes sense to make this generic in its current form because "spectre"
>>is a somewhat vague generic term.
>>
>>>This was the whole motivation for doing the same for x86.
>>>
>>>Adding a condition for all architectures is also okay, but its going to
>>>a little messier:
>>>
>>>	 config BPF_UNPRIV_DEFAULT_OFF
>>>	        default y if X86 || ARM || ...
>>>
>>>This approach would make sense if architectures wants to explicitly
>>>select the defaults irrespective of architecture being affected by
>>>spectre.
>>
>>If we're going to change the default for some architectures, I think
>>it'd make much more sense to just do that for all, without any
>>arch-specific conditionality, i.e.
>>
>>	config BPF_UNPRIV_DEFAULT_OFF
>>		default y
>
>Lets just go with 'default y'. The main rationale for this change was motivated
>by spectre, so would have been good to indicate this also with an explicit
>dependency for broken HW, not just help description. Pretty much agreeing with
>Greg here [0]. Eventually, we might need some arch generic way to determine arch-
>common spectre type bugs, so that for unaffected HW we don't need to apply some
>of them from verifier, but that's still tbd.

I will send a patch soon with 'default y'.

Thanks,
Pawan

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Russell King (Oracle)]

On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
> Isn't ARM already using CPU_SPECTRE for selecting things:
> 
> 	config HARDEN_BRANCH_PREDICTOR
> 	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
> 	     depends on CPU_SPECTRE
> 
> This was the whole motivation for doing the same for x86.
> 
> Adding a condition for all architectures is also okay, but its going to
> a little messier:
> 
> 	 config BPF_UNPRIV_DEFAULT_OFF
> 	        default y if X86 || ARM || ...

It doesn't have to be (but sadly we end up repeating "DEFAULT"):

config BPF_UNPRIV_DEFAULT_OFF_DEFAULT
	bool

config BPF_UNPRIV_DEFAULT_OFF
	bool "Disable unprivileged BPF by default"
	default BPF_UNPRIV_DEFAULT_OFF_DEFAULT

Then architectures can select BPF_UNPRIV_DEFAULT_OFF_DEFAULT if they
wish this to be defaulted to "yes".

However, please note that this has limited use given that the
BPF_UNPRIV_DEFAULT_OFF option has been around for a while now. Any
existing configuration that mentions this symbol will override any
default specified in the Kconfig files if the option is user-visible.

So, IMHO, defaults need to be set correctly from the point in time
that the option is introduced.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures

[Pawan Gupta]

On 29.10.2021 11:08, Russell King (Oracle) wrote:
>On Thu, Oct 28, 2021 at 12:36:58PM -0700, Pawan Gupta wrote:
>> Isn't ARM already using CPU_SPECTRE for selecting things:
>>
>> 	config HARDEN_BRANCH_PREDICTOR
>> 	     bool "Harden the branch predictor against aliasing attacks" if EXPERT
>> 	     depends on CPU_SPECTRE
>>
>> This was the whole motivation for doing the same for x86.
>>
>> Adding a condition for all architectures is also okay, but its going to
>> a little messier:
>>
>> 	 config BPF_UNPRIV_DEFAULT_OFF
>> 	        default y if X86 || ARM || ...
>
>It doesn't have to be (but sadly we end up repeating "DEFAULT"):
>
>config BPF_UNPRIV_DEFAULT_OFF_DEFAULT
>	bool
>
>config BPF_UNPRIV_DEFAULT_OFF
>	bool "Disable unprivileged BPF by default"
>	default BPF_UNPRIV_DEFAULT_OFF_DEFAULT
>
>Then architectures can select BPF_UNPRIV_DEFAULT_OFF_DEFAULT if they
>wish this to be defaulted to "yes".

Looks like we are settling on unconditional 'default y' for now [1].
I have sent a v3 with 'default y' [2].

>However, please note that this has limited use given that the
>BPF_UNPRIV_DEFAULT_OFF option has been around for a while now. Any
>existing configuration that mentions this symbol will override any
>default specified in the Kconfig files if the option is user-visible.

Yes, existing configurations will have to toggle this manually. However,
many distros already have BPF_UNPRIV_DEFAULT_OFF=y in their
configuration.

>So, IMHO, defaults need to be set correctly from the point in time
>that the option is introduced.

Agree.

[1] https://lore.kernel.org/lkml/6130e55f-4d84-5ada-4e86-5b678e3eaf5e@iogearbox.net/
[2] https://lore.kernel.org/lkml/0ace9ce3f97656d5f62d11093ad7ee81190c3c25.1635535215.git.pawan.kumar.gupta@linux.intel.com/