Netdev List
 help / color / mirror / Atom feed
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

      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