linux-kernel - Re: [PATCH v3 16/16] kunit: uapi: Validate usability of /proc

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: <20250620154408-bc103402-56f0-4ac1-a06f-63b2ed30ed29@linutronix.de>
Date: Fri, 20 Jun 2025 15:50:19 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: David Gow <davidgow@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, 
	Willy Tarreau <w@....eu>, Thomas Weißschuh <linux@...ssschuh.net>, 
	Brendan Higgins <brendan.higgins@...ux.dev>, Rae Moar <rmoar@...gle.com>, Shuah Khan <shuah@...nel.org>, 
	Jonathan Corbet <corbet@....net>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com, linux-doc@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, workflows@...r.kernel.org
Subject: Re: [PATCH v3 16/16] kunit: uapi: Validate usability of /proc

On Fri, Jun 20, 2025 at 05:48:07PM +0800, David Gow wrote:
> On Wed, 11 Jun 2025 at 15:38, Thomas Weißschuh
> <thomas.weissschuh@...utronix.de> wrote:
> >
> > Show that the selftests are executed from a fairly "normal"
> > userspace context.
> >
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
> > ---
> 
> This is good. I'm not 100% sure the example test is the best place for
> it, though.
> 
> Would it make more sense to either have this:
> - in the main kunit test (since it's really _verifying_ the KUnit
> environment, rather than documenting it)
> - in a separate kunit-uapi test (if we want to keep some separation
> between the UAPI and entirely in-kernel tests)
> - in a separate procfs test (since it tests procfs functionality as
> much as it's testing the KUnit environment)

Originally this change was really meant as an example for users.
But moving it into the main kunit test probably makes more sense.

> Personally, my gut feeling is the main kunit-test is the best place
> for this, even if it means spinning up a separate file is best here.

Ack.

> As for the actual implementation, though, that looks fine to me. A few
> small comments below, but nothing particularly important.
> 
> Reviewed-by: David Gow <davidgow@...gle.com>
> 
> Cheers,
> -- David
> 
> >  lib/kunit/kunit-example-uapi.c | 34 +++++++++++++++++++++++++++++++++-
> >  1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/kunit/kunit-example-uapi.c b/lib/kunit/kunit-example-uapi.c
> > index 4ce657050dd4a576632a41ca0309c4cb5134ce14..5e7a0f3b68f182c42b03e667567e66f02d8c2b86 100644
> > --- a/lib/kunit/kunit-example-uapi.c
> > +++ b/lib/kunit/kunit-example-uapi.c
> > @@ -8,13 +8,45 @@
> >   * This is *userspace* code.
> >   */
> >
> > +#include <fcntl.h>
> > +#include <unistd.h>
> > +#include <string.h>
> > +
> >  #include "../../tools/testing/selftests/kselftest.h"
> >
> > +static void test_procfs(void)
> > +{
> > +       char buf[256];
> > +       ssize_t r;
> > +       int fd;
> > +
> > +       fd = open("/proc/self/comm", O_RDONLY);
> > +       if (fd == -1) {
> > +               ksft_test_result_fail("procfs: open() failed: %s\n", strerror(errno));
> > +               return;
> > +       }
> > +
> > +       r = read(fd, buf, sizeof(buf));
> > +       close(fd);
> > +
> > +       if (r == -1) {
> > +               ksft_test_result_fail("procfs: read() failed: %s\n", strerror(errno));
> > +               return;
> > +       }
> > +
> 
> Do we want to use TASK_COMM_LEN rather than hardcoding 16 below?

> (And, if so, do we need something more complicated in case it's not 16?)

TASK_COMM_LEN is not part of the UAPI headers.
But I don't think it can ever change.

> > +       if (r != 16 || strncmp("kunit-example-u\n", buf, 16) != 0) {
> > +               ksft_test_result_fail("procfs: incorrect comm\n");
> > +               return;
> > +       }
> > +
> > +       ksft_test_result_pass("procfs\n");
> > +}
> > +
> >  int main(void)
> >  {
> >         ksft_print_header();
> >         ksft_set_plan(4);
> > -       ksft_test_result_pass("userspace test 1\n");
> > +       test_procfs();
> >         ksft_test_result_pass("userspace test 2\n");
> >         ksft_test_result_skip("userspace test 3: some reason\n");
> >         ksft_test_result_pass("userspace test 4\n");
> >
> > --
> > 2.49.0
> >