linux-kernel - Re: [PATCH 0/7] Make core VMA operations internal and testable

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: <1a41caa5-561e-415f-85f3-01b52b233506@lucifer.local>
Date: Wed, 3 Jul 2024 21:33:00 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Matthew Wilcox <willy@...radead.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Eric Biederman <ebiederm@...ssion.com>, Kees Cook <kees@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH 0/7] Make core VMA operations internal and testable

On Wed, Jul 03, 2024 at 01:26:53PM GMT, Andrew Morton wrote:
> On Wed,  3 Jul 2024 12:57:31 +0100 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
>
> > Kernel functionality is stubbed and shimmed as needed in tools/testing/vma/
> > which contains a fully functional userland vma_internal.h file and which
> > imports mm/vma.c and mm/vma.h to be directly tested from userland.
>
> Cool stuff.

Thanks :)

>
> Now we need to make sure that anyone who messes with vma code has run
> the tests.  And has added more testcases, if appropriate.
>
> Does it make sense to execute this test under selftests/ in some
> fashion?  Quite a few people appear to be running the selftest code
> regularly and it would be good to make them run this as well.

I think it will be useful to do that, yes, but as the tests are currently a
skeleton to both provide the stubbing out and to provide essentially an
example of how you might test (though enough that it'd now be easy to add a
_ton_ of tests), it's not quite ready to be run just yet.

>
> >  51 files changed, 3914 insertions(+), 2453 deletions(-)
>
> eep.  The best time for me to merge this is late in the -rc cycle so
> the large skew between mainline and mm.git doesn't spend months
> hampering ongoing development.  But that merge time is right now.

Argh. Well, the numbers are scary, but it's _mostly_ moving code around
with some pretty straightforward refactorings and adding a bunch of
userland code that won't impact kernels at all.

So I'd argue this is less crazy in size than it might seem...