[PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack

[Alan Maguire]

On Thu, 31 Oct 2019, Brendan Higgins wrote:

> On Wed, Oct 30, 2019 at 12:09 PM Kees Cook <keescook at chromium.org> wrote:
> >
> > On Thu, Oct 24, 2019 at 10:15:29AM +0000, Luis Chamberlain wrote:
> > > On Wed, Oct 23, 2019 at 05:42:18PM -0700, Brendan Higgins wrote:
> > > > With that, I think the best solution in this case will be the
> > > > "__visible_for_testing" route. It has no overhead when testing is
> > > > turned off (in fact it is no different in anyway when testing is
> > > > turned off). The downsides I see are:
> > > >
> > > > 1) You may not be able to test non-module code not compiled for
> > > > testing later with the test modules that Alan is working on (But the
> > > > only way I think that will work is by preventing the symbol from being
> > > > inlined, right?).
> > > >
> > > > 2) I think "__visible_for_testing" will be prone to abuse. Here, I
> > > > think there are reasons why we might want to expose these symbols for
> > > > testing, but not otherwise. Nevertheless, I think most symbols that
> > > > should be tested should probably be made visible by default. Since you
> > > > usually only want to test your public interfaces. I could very well
> > > > see this getting used as a kludge that gets used far too frequently.
> > >
> > > There are two parts to your statement on 2):
> > >
> > >   a) possible abuse of say __visible_for_testing
> >
> > I really don't like the idea of littering the kernel with these. It'll
> 
> Yeah, I kind of hope that it would make people think more
> intentionally about what is a public interface so that they wouldn't
> litter the kernel with those. But I agree that in the world where
> people *didn't* do that. Lots of these sprinkled around would be
> annoying.
> 
> > also require chunks in header files wrapped in #ifdefs. This is really
> 
> Why would it require header files wrapped in #ifdefs?
> 
> We could put all the ifdeffery logic in the __visible_for_testing
> macro so that nothing in the original code has to change except for
> adding an #include and replacing a couple of `static`s with
> `__visible_for_testing`.
> 

FWIW I think this approach, if used sparingly, is fine.  However I'd
propose a hierarchy of options when looking to expose interfaces for 
testing.

1. For small, largely self-contained functions, move their definitions 
from .c files to a .h file where those functions are defined as "static 
inline".  That way the original code and tests can included them and we 
have solved function availability for both the cases where the tests are 
built-in and compiled as a module.  The apparmor interfaces here seem to 
be candidates for that approach.

2. For more complex cases, __visible_for_testing (for built-in visbility)
and some sort of equivalent EXPORT_FOR_TESTING (for module 
visibility) would work, or the kunit_find_symbol() based lookup approach I 
suggested in the module patches.  Either of these allows for building 
tests as modules or builtin.

3. For some cases, module support will probably be impossible or difficult 
to maintain.  In such cases, builtin tests make most sense so any 
questions about symbol visibility would largely concern changing static 
definitions to be __visibile_for_testing, with no need for any symbol 
export for module visibility.


> > ugly.
> >
> > >   b) you typically only want to test your public interfaces
> >
> > True, but being able to test the little helper functions is a nice
> > starting point and a good building block.
> 
> Yeah, I think I have come to accept that. We can argue about how this
> should change and how people need to learn to be more intentional
> about which interfaces are public and many other high minded ideas,
> but when it comes down to it, we need to provide a starting point that
> is easy.
> 
> If our nice starting point becomes a problem, we can always improve it later.
> 
> > Why can't unit tests live with the code they're testing? They're already
> > logically tied together; what's the harm there? This needn't be the case
> > for ALL tests, etc. The test driver could still live externally. The
> > test in the other .c would just have exported functions... ?
> 
> Well, for one, it totally tanks certain cases for building KUnit tests
> as modules. I don't care about this point *too* much personally, but I
> accept that there are others that want this, and I don't want to make
> these people's lives too difficult.
>

Appreciated.  I think at this point it might be useful to lay out my 
thinking on why being able to build tests as modules may be helpful moving 
forward.

- First and foremost, if the functionality itself is predominantly 
delivered in module form, or indeed is simply tristate, having a way to 
test kernel code when built as a module seems to me to be necessary. To 
test module code with built-in test code seems broken, and even if it 
could be made to work we'd end up having to invent a bunch of the mechanisms
we'd need for building tests as modules anyway.

- Running tests on demand.  From previous discussions, I think this is 
wanted for kselftest, and if we have a set of modules with a conventional 
prefix (e.g. kunit-*), running tests becomes simply a "find + modprobe" in 
the kernel module tree.  Results could be harvested from debugfs (I have a 
WIP patch to store logging data in the per-test data structures such that 
"cat /sys/kernel/debug/kunit-results/kunit-foo" will display results for 
that test suite).  There are other ways to achieve this goal, and it's 
a crude method without any test selection beyond which modules are 
loaded, but this path is noticeably shorter to having a simple way to 
execute tests in a kselftest-friendly way I think. 

- Developing tests. I've also found this model to be neat for test 
development; add a test, build, load the module to test the test, add 
another test, build, unload/load etc. 

- The late_initcall() initialization of tests may not always be appropriate
for subsystems under test, and as the number of tests grow (a good 
problem to have!), it will likely become infeasible.

Anyway I'm not sure if any of the above resonates with others as being 
useful, but hopefully it clarifies why module support might matter moving 
forward.

If it makes sense, I can look at tweaking the module patchset to remove
the kunit_find_symbol() stuff so that we can punt on specific mechanisms 
for now; my main aim at this point is to ensure we're thinking about 
providing mechanisms for testing modules. 

Thanks!

Alan