Message-ID: <acbc0663-57a5-4643-88e0-33c7beeadc22@lucifer.local>
Date: Wed, 11 Dec 2024 08:35:16 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Jeff Xu <jeffxu@...omium.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>, akpm@...ux-foundation.org,
        vbabka@...e.cz, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org, linux-mm@...ck.org,
        jorgelo@...omium.org, keescook@...omium.org, pedro.falcato@...il.com,
        rdunlap@...radead.org, Jann Horn <jannh@...gle.com>,
        David Hildenbrand <david@...hat.com>
Subject: Re: [PATCH v1] mseal: move can_do_mseal to mseal.c

On Tue, Dec 10, 2024 at 06:38:49PM -0800, Jeff Xu wrote:
> Hi Lorenzo,
>
> Regarding your proposal of moving mseal.c to vma.c for unit testing.
>
> On Fri, Dec 6, 2024 at 9:04 AM Lorenzo Stoakes
> <lorenzo.stoakes@...cle.com> wrote:
> > > >
> > > > An aside - I actually think we need to move the bulk of this code to
> > > > mm/vma.c - it makes absolutely no sense to keep the internals in this file,
> > > > and that way we can userland test mseal functionality.
> > > >
> > > Is there a past discussion to read ? That will help me understand your
> > > strategy of unit testing mm code.
> > > Moving everything to vma.c, will lose log history, e.g. blame no
> > > longer helps, did we consider alternatives ?
> >
> > Re; git blame - I'm not sure what alternative you think exists, and I've
> > moved brk(), mmap(), etc. with a history spanning >30 years, so I'm not
> > sure what blame history you're concerned about given how recent mseal is :)
> >
> > There is always code that gets moved or changed. You can't stay attached to
> > your name appearing on a git blame line.
> >
> > Re: discussion, there's dozens of discussions and patch sets totalling ~3k
> > lines of code... just search lore for vma testing, or search through my
> > commits in mm/vma.c and you can see.
> >
> > I can put together links if you really need, but I think say [0] is a good
> > motivating example of how I was able to actually write unit tests for VMA
> > merge functionality which previously could not exist.
> >
> > In any case you can use the git blame -C option to 'see through' things like
> > code moves.
> >
> > The whole point of this is to be able to _unit_ test functionality under
> > circumstances that might be otherwise improbable/incredibly difficult to
> > obtain if run as part of a kernel and self testing.
> >
> > Importantly it allows us to conduct fuzzing testing in future, something
> > key and fundamental to security testing.
> >
> > I would say for somebody who has clearly stated his huge commitment to
> > testing and how critically vital it is especially in the security realm,
> > this is entirely something that is beneficial to the kernel and to mseal
> > stability and security.
> >
> > If you want to see it 'in action', you can run the tests in
> > tools/testing/vma via:
> >
> > $ make && ./vma
> >
> I want to express my support for unit testing and agree that more
> testing would benefit mm. However, I'm unsure about the reasoning
> behind moving code to vma.c in bulk. Could you please clarify this for
> me?
>
> In my understanding, unit tests can be conducted regardless of the
> code's location once dependencies are addressed with stubs. Have you
> considered adding mseal.c to the unittest makefile at the same level
> as vma.c? Since mseal.c doesn't introduce new dependencies, i.e. it
> operates directly on the vm_area_struct, so I would start with that.

These aren't ordinary unit tests, this is a whole new structure to allow
for _userland_ unit tests, that is the ability to compile kernel code in
userland.

The mm/vma.c file has been specially set up to allow for this, it
outsources its imports to vma_internal.h, one which exists in mm/ for the
kernel and one which exists in tools/testing/vma for the userland unit
tests.

It also strictly means that vma.c is _internal_ only and _cannot_ be used
from any other part of the kernel except mm - it's a sealed environment
unto itself.

None of these things are true of mseal.c.

In any case it was something I was considering, if it makes sense to. You
can see VMA manipulation code in mprotect.c, etc. which may not actually
make a huge amount of sense to move over.

So this isn't for certain, and you'll be involved in any discussion if this
were to be done... :)

>
> I guess, for UT, you might need to change some functions' signatures,
> e.g. remove static, if you want to test an internal function (e.g
> mseal_fixup) , from your unit-test, but this is the same even after
> moving them to vma.c.
>
> There will be additional work of clean up including header (".h"),
> still I believe this is the same work even after moving the code into
> vma.c. You might still need to move the prototype of some functions
> into vma.h or vma_internal.h (e.g. definition of MADV_FREE). But I
> think this work is also orthogonal to where the mseal business logic
> is located.
>
> I understand the logic behind the current vma.c (on the linux_main
> branch) and the unit test for the VMA merge functionality. However, if
> your plan is to move all VMA-related code into vma.c, that means more
> stubs are needed (depending on the boundary of the proposed unit
> testing), and I don't understand how moving the code can help reduce
> the amount of work or stubs (if that is the motivation).

Yeah it isn't to move _all_ VMA-related code, because some don't make sense
there, but rather core VMA operations which make sense to be there and also
tested.

The possibilities are pretty exciting as to what we can do with this (ok
maybe only to me but still :P).

So again, it's far from certain I'll try to do this with mseal, it was just
a heads up ahead of time just in case I do.

I mean speciflcally speaking it'd be the very straightforward stuff about
applying mseal flags, checking compatibility etc.

>
> To avoid spending too much of your time, if there are previous
> discussions on this topic, please share links or a brief summary, so I
> can study them first.

Sure, I mean again the best thing is the original series [1]

[1]:https://lore.kernel.org/all/cover.1722251717.git.lorenzo.stoakes@oracle.com/

>
> Thanks!
> Best Regards,
> -Jeff
>
>
> > [0]https://lore.kernel.org/linux-mm/1c7a0b43cfad2c511a6b1b52f3507696478ff51a.1725040657.git.lorenzo.stoakes@oracle.com/
> >
> > Thanks, Lorenzo

This won't happen until next year at the earliest anyway, as I'm off for
Christmas/NY at the end of this week and this is nowhere near my TODO list
even at the moment :)

Powered by blists - more mailing lists