All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: davem@davemloft.net, john.fastabend@gmail.com, ast@kernel.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] bpf: fix ri->map prog pointer on bpf_prog_realloc
Date: Tue, 19 Sep 2017 09:23:45 +0200	[thread overview]
Message-ID: <59C0C601.3060406@iogearbox.net> (raw)
In-Reply-To: <20170919014326.r4x5ymz33zecayas@ast-mbp>

On 09/19/2017 03:43 AM, Alexei Starovoitov wrote:
> On Tue, Sep 19, 2017 at 03:16:44AM +0200, Daniel Borkmann wrote:
>> Commit 109980b894e9 ("bpf: don't select potentially stale
>> ri->map from buggy xdp progs") passed the pointer to the prog
>> itself to be loaded into r4 prior on bpf_redirect_map() helper
>> call, so that we can store the owner into ri->map_owner out of
>> the helper.
>>
>> Issue with that is that the actual address of the prog is still
>> subject to change when subsequent rewrites occur, e.g. through
>> patching other helper functions or constant blinding. Thus, we
>> really need to take prog->aux as the address we're holding, and
>> then during runtime fetch the actual pointer via aux->prog. This
>> also works with prog clones as they share the same aux and fixup
>> pointer to self after blinding finished.
>>
>> Fixes: 109980b894e9 ("bpf: don't select potentially stale ri->map from buggy xdp progs")
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>>   kernel/bpf/verifier.c | 12 ++++++++++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 799b245..243c09f 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -4205,9 +4205,17 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
>>   		}
>>
>>   		if (insn->imm == BPF_FUNC_redirect_map) {
>> -			u64 addr = (unsigned long)prog;
>> +			/* Note, we cannot use prog directly as imm as subsequent
>> +			 * rewrites would still change the prog pointer. The only
>> +			 * stable address we can use is aux, which also works with
>> +			 * prog clones during blinding.
>> +			 */
>
> good catch. extra load at runtime sucks, but I don't see better solution.
>
>> +			u64 addr = (unsigned long)prog->aux;
>> +			const int r4 = BPF_REG_4;
>>   			struct bpf_insn r4_ld[] = {
>> -				BPF_LD_IMM64(BPF_REG_4, addr),
>> +				BPF_LD_IMM64(r4, addr),
>> +				BPF_LDX_MEM(BPF_DW, r4, r4,
>> +					    offsetof(struct bpf_prog_aux, prog)),
>
> needs to be BPF_FIELD_SIZEOF(struct bpf_prog_aux, prog) to work on 32-bit

Good point, will spin a v2. Thanks!

      reply	other threads:[~2017-09-19  7:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19  1:16 [PATCH net] bpf: fix ri->map prog pointer on bpf_prog_realloc Daniel Borkmann
2017-09-19  1:43 ` Alexei Starovoitov
2017-09-19  7:23   ` Daniel Borkmann [this message]

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=59C0C601.3060406@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=john.fastabend@gmail.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.