Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1611778pxb; Thu, 28 Oct 2021 06:59:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxd4tffahWPzoGmB3UUjdH1TP6OFVyDTa5zH4hHlFn8+VTkwL/wCNwzK4oKDTP5gFUxih3Q X-Received: by 2002:a17:90b:1b42:: with SMTP id nv2mr4784198pjb.196.1635429586913; Thu, 28 Oct 2021 06:59:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635429586; cv=none; d=google.com; s=arc-20160816; b=tb//ZkoiS3TXbNrIEB0/M+flsf1IP7163o7S8sa1MjV6p5QPnnuyL9Yszh1FJEjac7 /AzI4+Vu3pLCM4xmJiDglHt0bZ2S8yVlhZd7gKRrlFr4uhZIOyoF/rAMZg65mXTsHfsx wv7WzETl5AGPT/pPK/+IEtc+/fCVes4i/yIzAVliavVVZkbgXinuuVa4Q4sG3R5qnNo0 AcmPJz79dfMncpULQaQiQIqFmqgki3dlwR8OTz4rPFuOdUBNatunA84M3FwFVBSP2jci hCFfuqzp/eQaEtzxiHQDIKiEMhkA+w5rukrlRZ2a0EAg1z9iUrAzGC3lGoV8PkifBS6k 4FHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=SviBTT4cqM6Mrn7Hgft1gQP0PJCXTyykWxKVJGdqZe0=; b=lPX1xRKry+EJBM4gGxUoVFvbuckEHShpW+YLLQI2oLBw9dGTu+NAwFCFxkYlHgvk8z +JEQspdna6JPb8NA65VpOJj6Qdg168LfiNdeEbo82Ht0+Q+e9S9uoQ6hlQd8I65WPk/1 tHTom5pC8JwQAq2PdNod/Q00GrxXGWTgClSn7PDPdmJ2fO99yoMoq5fVnJCGlEqWdeON QGtZMUL7SwtOL7btGAOM5Pl3EG9I7eRlPZfoKonVboqBNh3Zm/s2lGCFZLETJt4WNWND nedECLxKcQntJxhSmoP75gWQlBHo5l0XbTExsNUhKvdot6KpYBDO8wT3tIMKNe36VbhR 3h4A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u13si4440014pfg.134.2021.10.28.06.59.34; Thu, 28 Oct 2021 06:59:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231168AbhJ1OAq (ORCPT + 99 others); Thu, 28 Oct 2021 10:00:46 -0400 Received: from foss.arm.com ([217.140.110.172]:55408 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230480AbhJ1OAi (ORCPT ); Thu, 28 Oct 2021 10:00:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F0BE61FB; Thu, 28 Oct 2021 06:58:10 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0105A3F70D; Thu, 28 Oct 2021 06:58:08 -0700 (PDT) Date: Thu, 28 Oct 2021 14:57:51 +0100 From: Mark Rutland To: Pawan Gupta Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , 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 Message-ID: <20211028135751.GA41384@lakrids.cambridge.arm.com> References: <882f5c31f48bac75ebaede2a0ec321ec67128229.1635383031.git.pawan.kumar.gupta@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <882f5c31f48bac75ebaede2a0ec321ec67128229.1635383031.git.pawan.kumar.gupta@linux.intel.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > [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 >