bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	linux-kernel@vger.kernel.org, antonio.gomez.iglesias@intel.com,
	tony.luck@intel.com, dave.hansen@linux.intel.com,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH ebpf v2 2/2] bpf: Make unprivileged bpf depend on CONFIG_CPU_SPECTRE
Date: Thu, 28 Oct 2021 14:57:51 +0100	[thread overview]
Message-ID: <20211028135751.GA41384@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <882f5c31f48bac75ebaede2a0ec321ec67128229.1635383031.git.pawan.kumar.gupta@linux.intel.com>

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
> 

  parent reply	other threads:[~2021-10-28 13:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28  1:32 [PATCH ebpf v2 0/2] Unprivileged BPF default Pawan Gupta
2021-10-28  1:35 ` [PATCH ebpf v2 2/2] bpf: Make unprivileged bpf depend on CONFIG_CPU_SPECTRE Pawan Gupta
2021-10-28  5:34   ` Greg KH
2021-10-28 19:38     ` Pawan Gupta
2021-10-28 13:57   ` Mark Rutland [this message]
2021-10-28 16:44     ` Greg KH
     [not found] ` <232b692cd79e4f6e4c3ee7055b5f02792a28d2c4.1635383031.git.pawan.kumar.gupta@linux.intel.com>
     [not found]   ` <20211028134918.GB48435@lakrids.cambridge.arm.com>
2021-10-28 19:36     ` [PATCH v2 1/2] arch/Kconfig: Make CONFIG_CPU_SPECTRE available for all architectures Pawan Gupta
2021-10-29  9:22       ` Mark Rutland
2021-10-29 16:05         ` Daniel Borkmann
2021-10-29 19:15           ` Pawan Gupta
2021-10-29 10:08       ` Russell King (Oracle)
2021-10-29 22:51         ` Pawan Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211028135751.GA41384@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=andrii@kernel.org \
    --cc=antonio.gomez.iglesias@intel.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=songliubraving@fb.com \
    --cc=tony.luck@intel.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).