Commit a657182a5c51 ("bpf: Don't use tnum_range on array range checking
for poke descriptors") has shown that using tnum_range() as argument to
tnum_in() can lead to misleading code that looks like tight bound check
when in fact the actual allowed range is much wider.
This patchset is a follow up of the above commit. I've audited other
usage of tnum_in() in verifier and have concluded that all of either
provides a tight bound check, or is using reg->var_off as the first
argument, and thus safe.
To prevent the problematic tnum_in(tnum_range(), ...) usage, add
documentation in the tnum.h header file to warn against it.
This is sent as an RFC for two reasons:
1. Gather feedback on whether it's possible to prevent the problematic
usage besides relying just on documentation.
One invasive option is to switch bound-checks done with
tnum_in(tnum_range(), ...) to use reg->u{min,max}_value instead,
which should always provide a tight bound check.
Alternatively maybe problematic usage can be detected through
development tool (sparse or Coccinelle?), but I know rather little
about them.
2. Attach a proof for the claimed safe usage of tnum_in(tnum_range(), ...)
found in patch 1, where the proof itself is not meant to be
merged.
Shung-Hsi Yu (2):
bpf: tnums: warn against the usage of tnum_in(tnum_range(), ...)
proof for the safe usage of tnum_in()
include/linux/tnum.h | 20 +++++-
tnum_in.py | 158 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 176 insertions(+), 2 deletions(-)
create mode 100755 tnum_in.py
--
2.37.2
