On Tue, Mar 4, 2025 at 6:14 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Tue, Mar 4, 2025 at 8:26 PM Blaise Boscaccy > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote: > > Paul Moore <paul@xxxxxxxxxxxxxx> writes: > > > On Tue, Mar 4, 2025 at 3:31 PM Blaise Boscaccy > > > <bboscaccy@xxxxxxxxxxxxxxxxxxx> wrote: > > >> > > >> The security_bpf LSM hook now contains a boolean parameter specifying > > >> whether an invocation of the bpf syscall originated from within the > > >> kernel. Here, we update the function signature of relevant test > > >> programs to include that new parameter. > > >> > > >> Signed-off-by: Blaise Boscaccy bboscaccy@xxxxxxxxxxxxxxxxxxx > > >> --- > > >> tools/testing/selftests/bpf/progs/rcu_read_lock.c | 3 ++- > > >> tools/testing/selftests/bpf/progs/test_cgroup1_hierarchy.c | 4 ++-- > > >> tools/testing/selftests/bpf/progs/test_kfunc_dynptr_param.c | 6 +++--- > > >> tools/testing/selftests/bpf/progs/test_lookup_key.c | 2 +- > > >> tools/testing/selftests/bpf/progs/test_ptr_untrusted.c | 2 +- > > >> tools/testing/selftests/bpf/progs/test_task_under_cgroup.c | 2 +- > > >> tools/testing/selftests/bpf/progs/test_verify_pkcs7_sig.c | 2 +- > > >> 7 files changed, 11 insertions(+), 10 deletions(-) > > > > > > I see that Song requested that the changes in this patch be split out > > > back in the v3 revision, will that cause git bisect issues if patch > > > 1/2 is applied but patch 2/2 is not, or is there some BPF magic that > > > ensures that the selftests will still run properly? > > > > > > > So there isn't any type checking in the bpf program's function > > arguments against the LSM hook definitions, so it shouldn't cause any > > build issues. To the best of my knowledge, the new is_kernel boolean > > flag will end up living in r3. None of the current tests reference > > that parameter, so if we bisected and ended up on the previous commit, > > the bpf test programs would in a worst-case scenario simply clobber that > > register, which shouldn't effect any test outcomes unless a test program > > was somehow dependent on an uninitialized value in a scratch register. > > Esh. With that in mind, I'd argue that the two patches really should > just be one patch as you did before. The patches are both pretty > small and obviously related so it really shouldn't be an issue. > > However, since we need this patchset in order to properly implement > BPF signature verification I'm not going to make a fuss if Song feels > strongly that the selftest changes should be split into their own > patch. On second thought, I think it makes sense to merge the two patches. Blasie, please update 1/2 based on Paul's comment, merge the two patches, and resend. You can keep my Acked-by. Do we need this in the LSM tree before the upcoming merge window? If not, we would prefer to carry it in bpf-next. Thanks, Song
