From: John Fastabend <john.fastabend@gmail.com>
To: Shung-Hsi Yu <shung-hsi.yu@suse.com>, lsf-pc@lists.linux-foundation.org
Cc: bpf@vger.kernel.org, Paul Chaignon <paul@isovalent.com>,
Eduard Zingerman <eddyz87@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>
Subject: RE: [LSF/MM/BPF TOPIC] Value Tracking in Verifier
Date: Thu, 29 Feb 2024 14:49:18 -0800 [thread overview]
Message-ID: <65e109eec79ef_43ad82086c@john.notmuch> (raw)
In-Reply-To: <ZeA9Jqug3NqPwjtQ@u94a>
Shung-Hsi Yu wrote:
> Hello,
>
> I'd like propose a discussion about BPF verifier itself. To avoid being too
> vague, this proposition limits to value tracking (i.e. var_off and
> *{min,max}_value in bpf_reg_state); taking a very brief look at the
> challenges of current implementation, and maybe alternative implementation
> like PREVAIL[1]. Before heading on to the actual discussion:
> - Unify signed and unsigned min/max tracking[2]
> - Refactor value tracking routines (as set-operations)
> - Tracking relation between values
Sounds interesting to me. Just creating a summarized list of the examples
that have forced the signed/unsigned separation would be valuable and the
reasons why we have both var_off and min,max would be a nice document.
The examples would show why the bit tracking and min/max has resisted
easily being unified.
>
> Admittedly the current topic is a rather narrowly scoped. The discussion
> could be further expanded to be about the verifier in general as needed,
> some (less concrete) ideas to discuss:
> - Further reducing loop/branch states
> - Lazier precision tracking
> - Simplification/refactoring of codebase
> - Documentation improvement
>
>
> Thanks,
> Shung-Hsi Yu
>
> 1: https://vbpf.github.io/
> 2: https://lore.kernel.org/bpf/20231108054611.19531-1-shung-hsi.yu@suse.com/
>
prev parent reply other threads:[~2024-02-29 22:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-29 8:15 [LSF/MM/BPF TOPIC] Value Tracking in Verifier Shung-Hsi Yu
2024-02-29 22:49 ` John Fastabend [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=65e109eec79ef_43ad82086c@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=eddyz87@gmail.com \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=paul@isovalent.com \
--cc=shung-hsi.yu@suse.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.