From: David Miller <davem@davemloft.net>
To: ecree@solarflare.com
Cc: ast@fb.com, daniel@iogearbox.net, alexei.starovoitov@gmail.com,
netdev@vger.kernel.org
Subject: Re: [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier.
Date: Wed, 17 May 2017 20:16:33 -0400 (EDT) [thread overview]
Message-ID: <20170517.201633.1413407173876329751.davem@davemloft.net> (raw)
In-Reply-To: <e873f261-e1c1-c344-3d72-254623e0c91a@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Wed, 17 May 2017 16:33:27 +0100
> So I did some experiments (in Python, script follows) and found that
> indeed this does appear to work, at least for addition and shifts.
> The idea is that we have a 0s mask and a 1s mask; for bits that are
> unknown, the 0s mask is set and the 1s mask is cleared. So a
> completely unknown variable has masks (~0, 0), then if you shift it
> left 2 you get (~3, 0) - just shift both masks. A constant x has
> masks (x, x) - all the 0s are known 0s and all the 1s are known 1s.
> Addition is a bit more complicated: we compute the 'unknown bits'
> mask, by XORing the 0s and 1s masks together, of each addend. Then
> we add the corresponding masks from each addend together, and force
> the 'unknown' bits to the appropriate values in each mask.
> So given (a1, b1) and (a2, b2), we compute m1 = a1 ^ b1,
> m2 = a2 ^ b2, and m = m1 | m2. Then a = (a1 + a2) | m, and
> b = (b1 + b2) & ~m.
> As a worked example, 2 + (x << 2) + 14:
> 2 => (2, 2) constant
> x => (~0, 0) unknown
> x << 2 => (~3, 0)
> 2 + (x << 2): add (2, 2) with (~3, 0)
> m1 = 0, m2 = ~3, m = ~3
> a = (2 + ~3) | ~3 = ~1 | ~3 = ~1
> b = (2 + 0) & ~~3 = 2 & 3 = 2
> so (~1, 2), which means "...xx10"
> now add 14: add (~1, 2) with (14, 14)
> m1 = ~3, m2 = 0, m = ~3
> a = (~1 + 14) | ~3 = 12 | ~3 = ~3
> b = (2 + 14) & ~~3 = 16 & 3 = 0
> so (~3, 0), which means "...xx00"
> and the result is 4-byte aligned.
Ok, I'm starting to digest this. If it works it's a nice universal
way to handle alignment tracking, that's for sure.
So, in C, addition (a += b) is something like:
struct bpf_reg_bits {
u64 zero_bits;
u64 one_bits;
};
static void add_update_bits(struct bpf_reg_bits *a, struct bpf_reg_bits *b)
{
u64 m_zeros, m_ones, m_all;
m_zeros = a->zero_bits ^ b->zero_bits;
m_ones = a->one_bits ^ b->one_bits;
m_all = m_zeros | m_ones;
a->zero_bits = (a->zero_bits + b->zero_bits) | m_all;
a->one_bits = (a->one_bits + b->zero_bits) & ~m_all;
}
Then, is subtraction merely:
static void sub_update_bits(struct bpf_reg_bits *a, struct bpf_reg_bits *b)
{
u64 m_zeros, m_ones, m_all;
m_zeros = a->zero_bits ^ b->zero_bits;
m_ones = a->one_bits ^ b->one_bits;
m_all = m_zeros | m_ones;
a->zero_bits = (a->zero_bits - b->zero_bits) | m_all;
a->one_bits = (a->one_bits - b->zero_bits) & ~m_all;
}
Or is something different needed?
What about multiplication? AND should be easy too.
BTW, we track something similar already in reg->imm which tracks how
many high order bits are known to be cleared in the register. It is
used to avoid potential overflow for packet pointer accesses. I bet
we can subsume that into this facility as well.
Thanks for all of your suggestions so far.
next prev parent reply other threads:[~2017-05-18 0:16 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-15 16:04 [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier David Miller
2017-05-16 12:37 ` Edward Cree
2017-05-16 19:52 ` David Miller
2017-05-16 22:53 ` Alexei Starovoitov
2017-05-17 14:00 ` Edward Cree
2017-05-17 15:33 ` Edward Cree
2017-05-18 0:16 ` David Miller [this message]
2017-05-18 1:18 ` Alexei Starovoitov
2017-05-18 14:10 ` Edward Cree
2017-05-18 2:48 ` Alexei Starovoitov
2017-05-18 14:49 ` Edward Cree
2017-05-18 16:38 ` Edward Cree
2017-05-18 18:41 ` Edward Cree
2017-05-19 1:22 ` Alexei Starovoitov
2017-05-19 14:21 ` Edward Cree
2017-05-19 14:55 ` Alexei Starovoitov
2017-05-19 17:17 ` Edward Cree
2017-05-19 20:00 ` Alignment in BPF verifier Edward Cree
2017-05-19 20:39 ` David Miller
2017-05-19 23:05 ` Daniel Borkmann
2017-05-23 14:41 ` Edward Cree
2017-05-23 17:43 ` Edward Cree
2017-05-23 23:59 ` Alexei Starovoitov
2017-05-23 19:45 ` Alexei Starovoitov
2017-05-23 21:27 ` Daniel Borkmann
2017-05-24 13:46 ` Edward Cree
2017-05-24 16:39 ` Alexei Starovoitov
2017-05-25 16:31 ` David Miller
2017-05-19 20:48 ` David Miller
2017-05-19 20:41 ` [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier David Miller
2017-05-19 21:37 ` Alexei Starovoitov
2017-05-19 23:16 ` David Miller
2017-05-20 0:20 ` Alexei Starovoitov
2017-05-17 16:13 ` David Miller
2017-05-17 17:00 ` Edward Cree
2017-05-17 17:25 ` 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=20170517.201633.1413407173876329751.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=alexei.starovoitov@gmail.com \
--cc=ast@fb.com \
--cc=daniel@iogearbox.net \
--cc=ecree@solarflare.com \
--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;
as well as URLs for NNTP newsgroup(s).