All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: ast@kernel.org, jannh@google.com, davem@davemloft.net,
	netdev@vger.kernel.org
Subject: Re: [PATCH bpf v2 8/9] bpf: prevent out of bounds speculation on pointer arithmetic
Date: Thu, 3 Jan 2019 00:37:36 +0100	[thread overview]
Message-ID: <388f895c-0247-d977-9e72-dfec39a5125d@iogearbox.net> (raw)
In-Reply-To: <20190102141101.58e28b28@cakuba.hsd1.ca.comcast.net>

On 01/02/2019 11:11 PM, Jakub Kicinski wrote:
> On Wed,  2 Jan 2019 00:20:45 +0100, Daniel Borkmann wrote:
>> Jann reported that the original commit back in b2157399cc98
>> ("bpf: prevent out-of-bounds speculation") was not sufficient
>> to stop CPU from speculating out of bounds memory access:
>> While b2157399cc98 only focussed on masking array map access
>> for unprivileged users for tail calls and data access such
>> that the user provided index gets sanitized from BPF program
>> and syscall side, there is still a more generic form affected
>> from BPF programs that applies to most maps that hold user
>> data in relation to dynamic map access when dealing with
>> unknown scalars or "slow" known scalars as access offset...
> 
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 8e5da1c..448a828 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -5499,6 +5610,13 @@ static bool states_equal(struct bpf_verifier_env *env,
>>  	if (old->curframe != cur->curframe)
>>  		return false;
>>  
>> +	/* Verification state from speculative execution simulation
>> +	 * must never prune a non-speculative execution one.
>> +	 */
>> +	if (old->speculative != cur->speculative ||
>> +	    (old->speculative && !cur->speculative))
>> +		return false;
> 
> nit: if I read this correctly it looks more conservative than the
>      comment suggests. 
> 
>      The second case (old->speculative && !cur->speculative) implies 
>      the first case (old->speculative != cur->speculative).
>      Perhaps:
> 
> 	if (old->speculative && !cur->speculative)
> 
>      Or:
> 
> 	if (old->speculative > cur->speculative)

Agree, and first one looks more readable.

>> +
>>  	/* for states to be equal callsites have to be the same
>>  	 * and all frame states need to be equivalent
>>  	 */
>> @@ -5530,6 +5648,11 @@ static int propagate_liveness(struct bpf_verifier_env *env,
>>  		     vparent->curframe, vstate->curframe);
>>  		return -EFAULT;
>>  	}
>> +
>> +	/* Don't propagate to non-speculative parent. */
>> +	if (vparent->speculative != vstate->speculative)
> 
> I haven't thought this trough fully, but is this really necessary?
> Do we assume the CPU will not speculate twice?  It seems not impossible
> to have a register only accessed on the speculation path, and therefore
> if we don't propagate liveness non-speculative walk may prune
> speculative checks.

This indeed needs to be removed from the patch, excellent catch; we definitely
don't want to run the risk of a reg being marked non-init in such case. I'll
spin v3 with both fixed up. Thanks for review!

>> +		return 0;
>> +
>>  	/* Propagate read liveness of registers... */
>>  	BUILD_BUG_ON(BPF_REG_FP + 1 != MAX_BPF_REG);
>>  	/* We don't need to worry about FP liveness because it's read-only */

  reply	other threads:[~2019-01-02 23:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01 23:20 [PATCH bpf v2 0/9] bpf fix to prevent oob under speculation Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 1/9] bpf: move {prev_,}insn_idx into verifier env Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 2/9] bpf: move tmp variable into ax register in interpreter Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 3/9] bpf: enable access to ax register also from verifier rewrite Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 4/9] bpf: restrict map value pointer arithmetic for unprivileged Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 5/9] bpf: restrict stack " Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 6/9] bpf: restrict unknown scalars of mixed signed bounds " Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 7/9] bpf: fix check_map_access smin_value test when pointer contains offset Daniel Borkmann
2019-01-01 23:20 ` [PATCH bpf v2 8/9] bpf: prevent out of bounds speculation on pointer arithmetic Daniel Borkmann
2019-01-02 22:11   ` Jakub Kicinski
2019-01-02 23:37     ` Daniel Borkmann [this message]
2019-01-01 23:20 ` [PATCH bpf v2 9/9] bpf: add various test cases to selftests Daniel Borkmann

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=388f895c-0247-d977-9e72-dfec39a5125d@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jannh@google.com \
    --cc=netdev@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.