linux-kernel - Re: [PATCH bpf-next v2 1/3] selftests/bpf: do not disable /dev/null device access in cgroup dev test

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <012176d7-646b-49fe-b139-c8072340ecdb@oracle.com>
Date: Tue, 30 Jul 2024 09:16:00 +0100
From: Alan Maguire <alan.maguire@...cle.com>
To: Alexis Lothoré <alexis.lothore@...tlin.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Martin KaFai Lau
 <martin.lau@...ux.dev>,
        Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
        Yonghong Song <yonghong.song@...ux.dev>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>, Stanislav Fomichev <sdf@...ichev.me>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Mykola Lysenko <mykolal@...com>, Shuah Khan <shuah@...nel.org>
Cc: ebpf@...uxfoundation.org, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>,
        bpf@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 1/3] selftests/bpf: do not disable /dev/null
 device access in cgroup dev test

On 29/07/2024 18:30, Alexis Lothoré wrote:
> Hello Alan,
> 
> On 7/29/24 18:59, Alan Maguire wrote:
>> On 29/07/2024 09:20, Alexis Lothoré (eBPF Foundation) wrote:
>>> test_dev_cgroup currently loads a small bpf program allowing any access on
>>> urandom and zero devices, disabling access to any other device. It makes
>>> migrating this test to test_progs impossible, since this one manipulates
>>> extensively /dev/null.
>>>
>>> Allow /dev/null manipulation in dev_cgroup program to make its usage in
>>> test_progs framework possible. Update test_dev_cgroup.c as well to match
>>> this change while it has not been removed.
>>>
>>> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@...tlin.com>
>>> ---
>>>  tools/testing/selftests/bpf/progs/dev_cgroup.c |  4 ++--
>>>  tools/testing/selftests/bpf/test_dev_cgroup.c  | 18 +++++++++---------
>>
>> Not a big deal, but I found it a bit confusing that this file was
>> modified then deleted in patch 2. Would it work having patch 1 stop
>> building the standalone test/remove it and .gitignore entry, patch 2
>> updating progs/dev_cgroup.c to allow /dev/zero, /dev/urandom access,
>> patch 3 add cgroup_dev.c test support, and patch 4 add the device type
>> subtest? Or are there issues with doing things that way? Thanks!
> 
> I've done this to make sure that at any point in the git history, there is one
> working test for the targeted feature, either the old or the new one. I've done
> it this way because the old test also helped me validate the new one while
> developing it, but also because if at some point there is a (major) issue with
> the new test, reverting only the relevant commit brings back the old test while
> disabling the new one.
> 
> But maybe this concern is not worth the trouble (especially since the old tests
> are not run automatically) ? If that's indeed the case, I can do it the way you
> are suggesting :)
>

If no-one complains, it seems fine to me to stick with the way you've
constructed the series the next respin. Thanks!

> Thanks,
> 
> Alexis
>