[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2278b1c7-5d20-3c89-eab1-ea34145dc73d@linux.intel.com>
Date: Tue, 8 Jan 2019 13:12:45 -0800
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Jiri Kosina <jikos@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Tom Lendacky <thomas.lendacky@....com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Andrea Arcangeli <aarcange@...hat.com>,
David Woodhouse <dwmw@...zon.co.uk>,
Andi Kleen <ak@...ux.intel.com>,
Dave Hansen <dave.hansen@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jon Masters <jcm@...hat.com>,
Waiman Long <longman9394@...il.com>,
Greg KH <gregkh@...uxfoundation.org>,
Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
x86@...nel.org, stable@...r.kernel.org, daniel@...earbox.net
Subject: Re: [PATCH] x86/speculation: Add document to describe Spectre and its
mitigations
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
Powered by blists - more mailing lists