Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 8 Jan 2019 17:11:32 -0800
From:   Alexei Starovoitov <alexei.starovoitov@gmail.com>
To:     Tim Chen <tim.c.chen@linux.intel.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Jiri Kosina <jikos@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        David Woodhouse <dwmw@amazon.co.uk>,
        Andi Kleen <ak@linux.intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        Jon Masters <jcm@redhat.com>,
        Waiman Long <longman9394@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        Borislav Petkov <bp@alien8.de>, linux-kernel@vger.kernel.org,
        x86@kernel.org, stable@vger.kernel.org, daniel@iogearbox.net,
        davem@davemloft.net
Subject: Re: [PATCH] x86/speculation: Add document to describe Spectre and
 its mitigations
Message-ID: <20190109011130.wrsrcaly2mgnou3k@ast-mbp>
References: <64efec3fda40c0758601bf9b1480a35d76d3c487.1545413988.git.tim.c.chen@linux.intel.com>
 <20181223231149.5yuenb53pavlvr3m@ast-mbp.dhcp.thefacebook.com>
 <2278b1c7-5d20-3c89-eab1-ea34145dc73d@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2278b1c7-5d20-3c89-eab1-ea34145dc73d@linux.intel.com>
User-Agent: NeoMutt/20180223
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Jan 08, 2019 at 01:12:45PM -0800, Tim Chen wrote:
> On 12/23/18 3:11 PM, Alexei Starovoitov wrote:
> > On Fri, Dec 21, 2018 at 09:44:44AM -0800, Tim Chen wrote:
> >> +
> >> +4. Kernel sandbox attacking kernel
> >> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> +
> >> +The kernel has support for running user-supplied programs within the
> >> +kernel.  Specific rules (such as bounds checking) are enforced on these
> >> +programs by the kernel to ensure that they do not violate access controls.
> >> +
> >> +eBPF is a kernel sub-system that uses user-supplied program
> >> +to execute JITed untrusted byte code inside the kernel. eBPF is used
> >> +for manipulating and examining network packets, examining system call
> >> +parameters for sand boxes and other uses.
> >> +
> >> +A malicious local process could upload and trigger an malicious
> >> +eBPF script to the kernel, with the script attacking the kernel
> >> +using variant 1 or 2 and reading memory.
> > 
> > Above is not correct.
> > The exploit for var2 does not load bpf progs into kernel.
> > Instead the bpf interpreter is speculatively executing bpf prog
> > that was never loaded.
> > Hence CONFIG_BPF_JIT_ALWAYS_ON=y is necessary to make var2 harder
> > to exploit.
> > Same goes for other in kernel interpreters and state machines.
> > 
> >> +
> >> +Necessary Prerequisites:
> >> +1. Malicious local process
> >> +2. eBPF JIT enabled for unprivileged users, attacking kernel with secrets
> >> +on the same machine.
> > 
> > This is not quite correct either.
> > Var 1 could have been exploited with and without JIT.
> > Also above sounds like that var1 is still exploitable through bpf
> > which is not the case.
> > 
> 
> Alexi,
> 
> Do you have any suggestions on how to rewrite this two paragraphs?  You
> are probably the best person to update content for this section.

how about moving bpf bits out of this doc and placing them under Documentation/bpf/ ?
We can create bpf_security.rst there with specdown mitigations, best practices,
useful sysctl and config knobs, etc.