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!
prev parent 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).