From: Daniel Borkmann <daniel@iogearbox•net>
To: Jakub Kicinski <jakub.kicinski@netronome•com>
Cc: netdev@vger•kernel.org, ast@kernel•org, kubakici@wp•pl
Subject: Re: [PATCHv6 net-next 04/15] bpf: don't (ab)use instructions to store state
Date: Mon, 19 Sep 2016 23:44:50 +0200 [thread overview]
Message-ID: <57E05C52.4060208@iogearbox.net> (raw)
In-Reply-To: <20160919223621.363c8ac5@jkicinski-Precision-T1700>
On 09/19/2016 11:36 PM, Jakub Kicinski wrote:
> On Mon, 19 Sep 2016 23:03:17 +0200, Daniel Borkmann wrote:
>> On 09/18/2016 05:09 PM, Jakub Kicinski wrote:
>>> Storing state in reserved fields of instructions makes
>>> it impossible to run verifier on programs already
>>> marked as read-only. Allocate and use an array of
>>> per-instruction state instead.
>>>
>>> While touching the error path rename and move existing
>>> jump target.
>>>
>>> Suggested-by: Alexei Starovoitov <ast@kernel•org>
>>> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome•com>
>>> Acked-by: Alexei Starovoitov <ast@kernel•org>
>>> Acked-by: Daniel Borkmann <daniel@iogearbox•net>
>>
>> I believe there's still an issue here. Could you please double check
>> and confirm?
>>
>> I rebased my locally pending stuff on top of your set and suddenly my
>> test case breaks. So I did a bisect and it pointed me to this commit
>> eventually.
>>
>> [...]
>>> @@ -2697,11 +2706,8 @@ static int convert_ctx_accesses(struct verifier_env *env)
>>> else
>>> continue;
>>>
>>> - if (insn->imm != PTR_TO_CTX) {
>>> - /* clear internal mark */
>>> - insn->imm = 0;
>>> + if (env->insn_aux_data[i].ptr_type != PTR_TO_CTX)
>>> continue;
>>> - }
>>>
>>> cnt = env->prog->aux->ops->
>>> convert_ctx_access(type, insn->dst_reg, insn->src_reg,
>>
>> Looking at the code, I believe the issue is in above snippet. In the
>> convert_ctx_accesses() rewrite loop, each time we bpf_patch_insn_single()
>> a program, the program can grow in size (due to __sk_buff access rewrite,
>> for example). After rewrite, we do 'i += insn_delta' for adjustment to
>> process next insn.
>>
>> However, env->insn_aux_data is alloced under the assumption that the
>> very initial, pre-verification prog->len doesn't change, right? So in
>> the above conversion access to env->insn_aux_data[i].ptr_type is off,
>> since after rewrites, corresponding mappings to ptr_type might not be
>> related anymore.
>>
>> I noticed this with direct packet access where suddenly the data vs
>> data_end test failed and contained some "semi-random" value always
>> bailing out for me.
>
> You are correct. Should I respin or would you like to post your set? :)
Heh, if you don't mind I would go ahead tonight, the conflict at two spots
when exposing verifier is really minor turns out. Are you okay with this?
What's the plan wrt env->insn_aux_data? Realloc plus rewrite of the array,
or do you see a more straight forward solution?
next prev parent reply other threads:[~2016-09-19 21:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 15:09 [PATCHv6 net-next 00/15] BPF hardware offload (cls_bpf for now) Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 01/15] net: cls_bpf: add hardware offload Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 02/15] net: cls_bpf: limit hardware offload by software-only flag Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 03/15] net: cls_bpf: add support for marking filters as hardware-only Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 04/15] bpf: don't (ab)use instructions to store state Jakub Kicinski
2016-09-19 21:03 ` Daniel Borkmann
2016-09-19 21:36 ` Jakub Kicinski
2016-09-19 21:44 ` Daniel Borkmann [this message]
2016-09-19 21:48 ` Jakub Kicinski
2016-09-19 21:55 ` Daniel Borkmann
2016-09-18 15:09 ` [PATCHv6 net-next 05/15] bpf: expose internal verfier structures Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 06/15] bpf: enable non-core use of the verfier Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 07/15] bpf: recognize 64bit immediate loads as consts Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 08/15] nfp: add BPF to NFP code translator Jakub Kicinski
2016-09-18 15:44 ` Daniel Borkmann
2016-09-18 15:09 ` [PATCHv6 net-next 09/15] nfp: bpf: add hardware bpf offload Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 10/15] net: cls_bpf: allow offloaded filters to update stats Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 11/15] nfp: bpf: " Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 12/15] nfp: bpf: add packet marking support Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 13/15] net: act_mirred: allow statistic updates from offloaded actions Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 14/15] nfp: bpf: add support for legacy redirect action Jakub Kicinski
2016-09-18 15:09 ` [PATCHv6 net-next 15/15] nfp: bpf: add offload of TC direct action mode Jakub Kicinski
2016-09-20 2:08 ` [PATCHv6 net-next 00/15] BPF hardware offload (cls_bpf for now) David Miller
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=57E05C52.4060208@iogearbox.net \
--to=daniel@iogearbox$(echo .)net \
--cc=ast@kernel$(echo .)org \
--cc=jakub.kicinski@netronome$(echo .)com \
--cc=kubakici@wp$(echo .)pl \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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