From: Edward Cree <ecree@solarflare.com>
To: Daniel Borkmann <daniel@iogearbox.net>,
Arthur Fabre <afabre@cloudflare.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst
Date: Mon, 30 Jul 2018 17:40:53 +0100 [thread overview]
Message-ID: <d3ec24aa-c655-d14b-0dd1-720118adabc4@solarflare.com> (raw)
In-Reply-To: <64b39825-3f74-15f6-6212-057c96a84999@iogearbox.net>
On 30/07/18 13:03, Daniel Borkmann wrote:
> On 07/30/2018 12:58 PM, Arthur Fabre wrote:
>> The check_alu_op() call handles 32bit and 64bit cases, but then in the
>> 32bit case
>> mark_reg_unknown() is called, discarding all the dst register state.
>> I think this is equivalent to keeping a copy of dst and always marking
>> dst as unknown.
>>
>> I think we could actually always use check_reg_arg() with DST_OP_NO_MARK:
>>
>> In the 32bit case, we call mark_reg_unknown() anyways.
>>
>> In the 64bit case, we copy src to dst, so marking dst as unknown is pointless.
>>
>> For plain BPF, we call __mark_reg_known() anyways.
> For imms this approach would be buggy since we leave a stale reg->off behind
> which is uncleared from previous reg state. So for them the mark_reg_unknown()
> is useful in the sense that it clears all reg state whereas __mark_reg_known()
> might only initialize a subset of it.
I guess the right thing is to change the existing call to DST_OP_NO_MARK,
and then in the "case: R = imm" branch add another check_reg_arg(DST_OP)
(or maybe just a mark_reg_unknown()).
-Ed
prev parent reply other threads:[~2018-07-30 18:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-25 22:08 [PATCH] bpf: verifier: BPF_MOV don't mark dst reg if src == dst Arthur Fabre
2018-07-26 0:42 ` Daniel Borkmann
2018-07-26 16:52 ` Arthur Fabre
2018-07-26 23:21 ` Y Song
2018-07-30 7:40 ` Arthur Fabre
2018-07-29 15:59 ` Alexei Starovoitov
2018-07-30 7:44 ` Arthur Fabre
2018-07-30 9:10 ` Daniel Borkmann
2018-07-30 10:58 ` Arthur Fabre
2018-07-30 12:03 ` Daniel Borkmann
2018-07-30 16:40 ` Edward Cree [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=d3ec24aa-c655-d14b-0dd1-720118adabc4@solarflare.com \
--to=ecree@solarflare.com \
--cc=afabre@cloudflare.com \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--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