From mboxrd@z Thu Jan  1 00:00:00 1970
Return-path: <ak@linux.intel.com>
Received: from mga02.intel.com ([134.134.136.20])
	by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
	(Exim 4.80)
	(envelope-from <ak@linux.intel.com>)
	id 1fJRnQ-0003E6-FA
	for speck@linutronix.de; Fri, 18 May 2018 00:54:53 +0200
Date: Thu, 17 May 2018 15:54:48 -0700
From: Andi Kleen <ak@linux.intel.com>
Subject: [MODERATED] Re: Generic eBPF hardening
Message-ID: <20180517225448.GC4486@tassilo.jf.intel.com>
References: <edeaf2b7-3219-9d21-4c73-b1545a197303@intel.com>
 <20180517222233.xk3favfebt4wiiid@ast-mbp>
MIME-Version: 1.0
In-Reply-To: <20180517222233.xk3favfebt4wiiid@ast-mbp>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: speck@linutronix.de
List-ID: <speck.linutronix.de>

On Thu, May 17, 2018 at 03:22:35PM -0700, speck for Alexei Starovoitov wrote:
> On Thu, May 17, 2018 at 01:55:38PM -0700, speck for Dave Hansen wrote:
> > I'm hoping Alexei is on the list now.
> > 
> > Andi Kleen and I were talking about ways to generally harden eBPF.  We
> > were a bit concerned that eBPF could leave around attacker-controlled
> > values on the stack that might allow later, speculatively-executed
> > kernel code to be exploited.
> > 
> > One thing I wanted to clarify: The eBPF stack (BPF_REG_FP) *is* the
> > kernel stack, correct?
> 
> yes. bpf program stack is kernel stack,
> but I don't see how this is useful.
> There are plenty of ways to populate kernel stack with user controlled
> bytes. Ex: set_task_comm.

EBPF has quite a bit more control over the exact layout than other 
buffers. 

Over time we should probably migrate most people who do copy_to_user
to stack buffers to do so onto the heap. But that's a longer term
project.

Luckily stack buffers are usually quite limited in size 
so attacks are likely harder.

But with EBPF controlling the exact layout it should be easier.

Would be better to fix it, especially since the fixes should be cheap.

-Andi