stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.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
Subject: Re: [PATCH] x86/speculation: Add document to describe Spectre and its mitigations
Date: Tue, 8 Jan 2019 13:12:45 -0800	[thread overview]
Message-ID: <2278b1c7-5d20-3c89-eab1-ea34145dc73d@linux.intel.com> (raw)
In-Reply-To: <20181223231149.5yuenb53pavlvr3m@ast-mbp.dhcp.thefacebook.com>

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.

Thanks.

Tim

  reply	other threads:[~2019-01-08 21:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 17:44 [PATCH] x86/speculation: Add document to describe Spectre and its mitigations Tim Chen
2018-12-21 21:59 ` Ben Greear
2018-12-22  1:17   ` Tim Chen
2018-12-31 16:22     ` Ben Greear
2018-12-31 17:10       ` Arjan van de Ven
2019-01-07 17:57       ` Tim Chen
2019-01-09  0:58         ` Ben Greear
2019-01-09  1:35           ` Tim Chen
2018-12-23 23:11 ` Alexei Starovoitov
2019-01-08 21:12   ` Tim Chen [this message]
2019-01-09  1:11     ` Alexei Starovoitov
2019-01-09  1:41       ` Tim Chen
2019-01-09  2:42         ` Alexei Starovoitov
2018-12-28 17:34 ` Jonathan Corbet
2019-01-08 21:18   ` Tim Chen
2019-01-13 23:10     ` Pavel Machek
2019-01-13 23:12       ` Jiri Kosina
2019-01-14 12:01         ` Pavel Machek
2019-01-14 12:06           ` Jiri Kosina
2019-01-14 13:01             ` Pavel Machek
2019-01-14 13:06               ` Jiri Kosina
2019-01-14 14:39                 ` Arjan van de Ven
2019-01-30  0:12 ` Thomas Gleixner
2019-02-12 12:00   ` Thomas Gleixner
2019-02-12 17:36     ` Tim Chen

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=2278b1c7-5d20-3c89-eab1-ea34145dc73d@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=arjan@linux.intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=bp@alien8.de \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jcm@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman9394@gmail.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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).