netdev.vger.kernel.org archive mirror
 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 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).