linux-kernel - Re: [PATCH bpf-next v6 5/5] bpf: selftests: verifier: Add nullness elision tests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cf0da119ef36fed757198a870952763a0cf48513.camel@gmail.com>
Date: Thu, 02 Jan 2025 19:16:39 -0800
From: Eduard Zingerman <eddyz87@...il.com>
To: Daniel Xu <dxu@...uu.xyz>, andrii@...nel.org, ast@...nel.org, 
	shuah@...nel.org, daniel@...earbox.net
Cc: martin.lau@...ux.dev, song@...nel.org, yonghong.song@...ux.dev, 
	john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
 haoluo@...gle.com, 	jolsa@...nel.org, mykolal@...com, bpf@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v6 5/5] bpf: selftests: verifier: Add nullness
 elision tests

On Thu, 2024-12-19 at 21:09 -0700, Daniel Xu wrote:
> Test that nullness elision works for common use cases. For example, we
> want to check that both constant scalar spills and STACK_ZERO functions.
> As well as when there's both const and non-const values of R2 leading up
> to a lookup. And obviously some bound checks.
> 
> Particularly tricky are spills both smaller or larger than key size. For
> smaller, we need to ensure verifier doesn't let through a potential read
> into unchecked bytes. For larger, endianness comes into play, as the
> native endian value tracked in the verifier may not be the bytes the
> kernel would have read out of the key pointer. So check that we disallow
> both.
> 
> Signed-off-by: Daniel Xu <dxu@...uu.xyz>
> ---

Nit: a few cases are omitted from these tests:
     1. a key is not a pointer to stack;
     2. a key is not a constant pointer;
     3. value on stack is not a spill;
     4. precision mark for stack value;

     I think (1) and (4) are worth testing.

     For (4) I think matching log messages about marking stack slot
     precise should be sufficient (register and slot index numbers are
     not guaranteed since tests are written in C, but regular expressions
     could be used in __msg using '{{' '}}' brackets, e.g.: '{{r[0-9]}}'.

     An alternative would be to write a test case where precision mark
     matters (a branch before map lookup with invalid key value used
     in a branch that is verified second). Such test would have to
     be written in inline assembly to guarantee code verification order.
     This might be an overkill.

[...]