From: Jiong Wang <jiong.wang@netronome.com>
To: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Edward Cree <ecree@solarflare.com>,
alexei.starovoitov@gmail.com, daniel@iogearbox.net,
oss-drivers@netronome.com, netdev@vger.kernel.org
Subject: Re: [oss-drivers] Re: [PATCH bpf] bpf: verifier: make sure callees don't prune with caller differences
Date: Thu, 13 Dec 2018 10:52:34 +0000 [thread overview]
Message-ID: <87k1kdu2a5.fsf@netronome.com> (raw)
In-Reply-To: <20181212160210.45b2b1ff@cakuba.netronome.com>
Jakub Kicinski writes:
<snip>
>> Is that just an optimisation that we can do because we know caller's
>> r1-r5 were scratched by the call?
(resent, got a bounce back from netdev mailing list for previous email)
I had been pondering whether it is really necessary to mark caller saved
registers as scratched. I kind of feel the following code inside
check_func_call might cause valid program rejected:
/* after the call registers r0 - r5 were scratched */
for (i = 0; i < CALLER_SAVED_REGS; i++) {
mark_reg_not_init(env, caller->regs, caller_saved[i]);
check_reg_arg(env, caller_saved[i], DST_OP_NO_MARK);
}
Because there is inter-procedure register allocation support in LLVM
(-enable-ipra), which could effectively eliminate register save/restore for
one caller-saved register across function call if the compiler can prove
callee or any other childs on the callgraph doesn't use/clobber this
particular caller-saved register. Then the later sequence in caller after
the call site could just safely read the caller-saved without restoring it
from stack etc. But we are marking all caller-saved as NOT_INIT, such read
will be treated as reading from uninitialized value, so the program will be
rejected.
-enable-ipra is disabled at default at the moment.
Regards,
Jiong
> r0 - r5 of the caller will not be pushed to the stack by JITs and
> therefore those are really dead. It is an optimization. We could've
> connected them but they are already marked as WRITTEN in
> check_func_call().
>
>> It looks like, without that, the change is "every reg in all frames
>> needs to be parented to the new-state", which is somewhat easier to
>> understand (though I did have to think for quite a long time before
>> it made sense to me why even that was necessary ;-)
>
> Ack, that was my initial patch actually, but Jiong pointed out it's
> unnecessary and I didn't argue :) r1 - r5 are marked as WRITTEN and
> UNINIT anyway, and r0 gets its parent from the callees frame
> (prepare_func_exit() links callers r0 parentage chain to previous
> states in the callee).
next prev parent reply other threads:[~2018-12-13 10:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-10 19:35 [PATCH bpf] bpf: verifier: make sure callees don't prune with caller differences Jakub Kicinski
2018-12-10 22:14 ` Jakub Kicinski
2018-12-12 4:39 ` Alexei Starovoitov
2018-12-12 20:28 ` Edward Cree
2018-12-13 0:02 ` Jakub Kicinski
2018-12-13 10:52 ` Jiong Wang [this message]
2018-12-13 16:40 ` [oss-drivers] " Edward Cree
2018-12-13 18:57 ` Alexei Starovoitov
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=87k1kdu2a5.fsf@netronome.com \
--to=jiong.wang@netronome.com \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=ecree@solarflare.com \
--cc=jakub.kicinski@netronome.com \
--cc=netdev@vger.kernel.org \
--cc=oss-drivers@netronome.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.