diff mbox series

[v6,3/4] kunit: Taint the kernel when KUnit tests are run

Message ID 20220708044847.531566-3-davidgow@google.com (mailing list archive)
State New, archived
Headers show
Series [v6,1/4] panic: Taint kernel if tests are run | expand

Commit Message

David Gow July 8, 2022, 4:48 a.m. UTC
Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
Due to KUnit tests not being intended to run on production systems, and
potentially causing problems (or security issues like leaking kernel
addresses), the kernel's state should not be considered safe for
production use after KUnit tests are run.

This both marks KUnit modules as test modules using MODULE_INFO() and
manually taints the kernel when tests are run (which catches builtin
tests).

Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Tested-by: Daniel Latypov <dlatypov@google.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Signed-off-by: David Gow <davidgow@google.com>
---

No changes since v5:
https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/

No changes since v4:
https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/

Changes since v3:
https://lore.kernel.org/lkml/20220513083212.3537869-2-davidgow@google.com/
- Use MODULE_INFO() for KUnit modules.
  - This is technically redundant, as the KUnit executor will taint the
    kernel when _any_ KUnit tests are run, but may be useful if some
    other tool will parse the 'test' property.
- Add {Acked,Tested,Reviewed}-by tags.

---
 include/kunit/test.h | 3 ++-
 lib/kunit/test.c     | 4 ++++
 2 files changed, 6 insertions(+), 1 deletion(-)

Comments

Shuah Khan July 8, 2022, 8:22 p.m. UTC | #1
On 7/7/22 10:48 PM, David Gow wrote:
> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> Due to KUnit tests not being intended to run on production systems, and
> potentially causing problems (or security issues like leaking kernel
> addresses), the kernel's state should not be considered safe for
> production use after KUnit tests are run.
> 
> This both marks KUnit modules as test modules using MODULE_INFO() and
> manually taints the kernel when tests are run (which catches builtin
> tests).
> 
> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> Tested-by: Daniel Latypov <dlatypov@google.com>
> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
> Signed-off-by: David Gow <davidgow@google.com>
> ---
> 
> No changes since v5:
> https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
> 
> No changes since v4:
> https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
> 

David, Brendan, Andrew,

Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
to linux-kselftest kunit for 5.20-rc1.

I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
me to drop the two I applied? Do we have to refresh with v6?

thanks,
-- Shuah
Daniel Latypov July 8, 2022, 9 p.m. UTC | #2
On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> On 7/7/22 10:48 PM, David Gow wrote:
> > Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> > Due to KUnit tests not being intended to run on production systems, and
> > potentially causing problems (or security issues like leaking kernel
> > addresses), the kernel's state should not be considered safe for
> > production use after KUnit tests are run.
> >
> > This both marks KUnit modules as test modules using MODULE_INFO() and
> > manually taints the kernel when tests are run (which catches builtin
> > tests).
> >
> > Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> > Tested-by: Daniel Latypov <dlatypov@google.com>
> > Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
> > Signed-off-by: David Gow <davidgow@google.com>
> > ---
> >
> > No changes since v5:
> > https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
> >
> > No changes since v4:
> > https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
> >
>
> David, Brendan, Andrew,
>
> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
> to linux-kselftest kunit for 5.20-rc1.
> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
> me to drop the two I applied? Do we have to refresh with v6?

Just noting here that there'll be a merge conflict between this patch
(3/4) and some other patches lined up to go through the kunit tree:
https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/

Not sure how we want to handle that.

Daniel
Shuah Khan July 8, 2022, 9:22 p.m. UTC | #3
On 7/8/22 3:00 PM, Daniel Latypov wrote:
> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>> On 7/7/22 10:48 PM, David Gow wrote:
>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>> Due to KUnit tests not being intended to run on production systems, and
>>> potentially causing problems (or security issues like leaking kernel
>>> addresses), the kernel's state should not be considered safe for
>>> production use after KUnit tests are run.
>>>
>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>> manually taints the kernel when tests are run (which catches builtin
>>> tests).
>>>
>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>>> Tested-by: Daniel Latypov <dlatypov@google.com>
>>> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
>>> Signed-off-by: David Gow <davidgow@google.com>
>>> ---
>>>
>>> No changes since v5:
>>> https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
>>>
>>> No changes since v4:
>>> https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
>>>
>>
>> David, Brendan, Andrew,
>>
>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>> to linux-kselftest kunit for 5.20-rc1.
>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>> me to drop the two I applied? Do we have to refresh with v6?
> 
> Just noting here that there'll be a merge conflict between this patch
> (3/4) and some other patches lined up to go through the kunit tree:
> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
> 
> Not sure how we want to handle that.
> 

I can go drop the two patches and have Andrew carry the series through
mm tree.

thanks,
-- Shuah
Shuah Khan July 8, 2022, 9:24 p.m. UTC | #4
On 7/8/22 3:22 PM, Shuah Khan wrote:
> On 7/8/22 3:00 PM, Daniel Latypov wrote:
>> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>
>>> On 7/7/22 10:48 PM, David Gow wrote:
>>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>>> Due to KUnit tests not being intended to run on production systems, and
>>>> potentially causing problems (or security issues like leaking kernel
>>>> addresses), the kernel's state should not be considered safe for
>>>> production use after KUnit tests are run.
>>>>
>>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>>> manually taints the kernel when tests are run (which catches builtin
>>>> tests).
>>>>
>>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>>>> Tested-by: Daniel Latypov <dlatypov@google.com>
>>>> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
>>>> Signed-off-by: David Gow <davidgow@google.com>
>>>> ---
>>>>
>>>> No changes since v5:
>>>> https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
>>>>
>>>> No changes since v4:
>>>> https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
>>>>
>>>
>>> David, Brendan, Andrew,
>>>
>>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>>> to linux-kselftest kunit for 5.20-rc1.
>>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>>> me to drop the two I applied? Do we have to refresh with v6?
>>
>> Just noting here that there'll be a merge conflict between this patch
>> (3/4) and some other patches lined up to go through the kunit tree:
>> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
>>
>> Not sure how we want to handle that.
>>
> 
> I can go drop the two patches and have Andrew carry the series through
> mm tree.
> 

Sorry spoke too soon. Yes there are others that might have conflicts as
Daniel pointed out:

https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/

thanks,
-- Shuah
David Gow July 9, 2022, 3:35 a.m. UTC | #5
On Sat, Jul 9, 2022 at 5:24 AM Shuah Khan <skhan@linuxfoundation.org> wrote:
>
> On 7/8/22 3:22 PM, Shuah Khan wrote:
> > On 7/8/22 3:00 PM, Daniel Latypov wrote:
> >> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
> >>>
> >>> On 7/7/22 10:48 PM, David Gow wrote:
> >>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
> >>>> Due to KUnit tests not being intended to run on production systems, and
> >>>> potentially causing problems (or security issues like leaking kernel
> >>>> addresses), the kernel's state should not be considered safe for
> >>>> production use after KUnit tests are run.
> >>>>
> >>>> This both marks KUnit modules as test modules using MODULE_INFO() and
> >>>> manually taints the kernel when tests are run (which catches builtin
> >>>> tests).
> >>>>
> >>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
> >>>> Tested-by: Daniel Latypov <dlatypov@google.com>
> >>>> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
> >>>> Signed-off-by: David Gow <davidgow@google.com>
> >>>> ---
> >>>>
> >>>> No changes since v5:
> >>>> https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
> >>>>
> >>>> No changes since v4:
> >>>> https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
> >>>>
> >>>
> >>> David, Brendan, Andrew,
> >>>
> >>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
> >>> to linux-kselftest kunit for 5.20-rc1.
> >>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
> >>> me to drop the two I applied? Do we have to refresh with v6?
> >>
> >> Just noting here that there'll be a merge conflict between this patch
> >> (3/4) and some other patches lined up to go through the kunit tree:
> >> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
> >>
> >> Not sure how we want to handle that.
> >>
> >
> > I can go drop the two patches and have Andrew carry the series through
> > mm tree.
> >
>
> Sorry spoke too soon. Yes there are others that might have conflicts as
> Daniel pointed out:
>
> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
>
> thanks,
> -- Shuah
>

Thanks everyone for pointing these out.

I've rebased the other series (the KUnit module support one:
https://lore.kernel.org/linux-kselftest/20220709032001.819487-1-davidgow@google.com/
) on top of this.

If they all go in via the kselftest/kunit tree, everything should be fine now.

Cheers,
-- David
Shuah Khan July 11, 2022, 11:17 p.m. UTC | #6
On 7/8/22 9:35 PM, David Gow wrote:
> On Sat, Jul 9, 2022 at 5:24 AM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>
>> On 7/8/22 3:22 PM, Shuah Khan wrote:
>>> On 7/8/22 3:00 PM, Daniel Latypov wrote:
>>>> On Fri, Jul 8, 2022 at 1:22 PM Shuah Khan <skhan@linuxfoundation.org> wrote:
>>>>>
>>>>> On 7/7/22 10:48 PM, David Gow wrote:
>>>>>> Make KUnit trigger the new TAINT_TEST taint when any KUnit test is run.
>>>>>> Due to KUnit tests not being intended to run on production systems, and
>>>>>> potentially causing problems (or security issues like leaking kernel
>>>>>> addresses), the kernel's state should not be considered safe for
>>>>>> production use after KUnit tests are run.
>>>>>>
>>>>>> This both marks KUnit modules as test modules using MODULE_INFO() and
>>>>>> manually taints the kernel when tests are run (which catches builtin
>>>>>> tests).
>>>>>>
>>>>>> Acked-by: Luis Chamberlain <mcgrof@kernel.org>
>>>>>> Tested-by: Daniel Latypov <dlatypov@google.com>
>>>>>> Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
>>>>>> Signed-off-by: David Gow <davidgow@google.com>
>>>>>> ---
>>>>>>
>>>>>> No changes since v5:
>>>>>> https://lore.kernel.org/linux-kselftest/20220702040959.3232874-3-davidgow@google.com/
>>>>>>
>>>>>> No changes since v4:
>>>>>> https://lore.kernel.org/linux-kselftest/20220701084744.3002019-3-davidgow@google.com/
>>>>>>
>>>>>
>>>>> David, Brendan, Andrew,
>>>>>
>>>>> Just confirming the status of these patches. I applied v4 1/3 and v4 3/4
>>>>> to linux-kselftest kunit for 5.20-rc1.
>>>>> I am seeing v5 and v6 now. Andrew applied v5 looks like. Would you like
>>>>> me to drop the two I applied? Do we have to refresh with v6?
>>>>
>>>> Just noting here that there'll be a merge conflict between this patch
>>>> (3/4) and some other patches lined up to go through the kunit tree:
>>>> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
>>>>
>>>> Not sure how we want to handle that.
>>>>
>>>
>>> I can go drop the two patches and have Andrew carry the series through
>>> mm tree.
>>>
>>
>> Sorry spoke too soon. Yes there are others that might have conflicts as
>> Daniel pointed out:
>>
>> https://patchwork.kernel.org/project/linux-kselftest/patch/20220625050838.1618469-2-davidgow@google.com/
>>
>> thanks,
>> -- Shuah
>>
> 
> Thanks everyone for pointing these out.
> 
> I've rebased the other series (the KUnit module support one:
> https://lore.kernel.org/linux-kselftest/20220709032001.819487-1-davidgow@google.com/
> ) on top of this.
> 
> If they all go in via the kselftest/kunit tree, everything should be fine now.
> 
> Cheers,
> -- David
> 

Thank you David. All patches applied now to linux-kselftest kunit for 5.20-rc1

thanks,
-- Shuah
diff mbox series

Patch

diff --git a/include/kunit/test.h b/include/kunit/test.h
index 8ffcd7de9607..ccae848720dc 100644
--- a/include/kunit/test.h
+++ b/include/kunit/test.h
@@ -277,7 +277,8 @@  static inline int kunit_run_all_tests(void)
 	{								\
 		return __kunit_test_suites_exit(__suites);		\
 	}								\
-	module_exit(kunit_test_suites_exit)
+	module_exit(kunit_test_suites_exit)				\
+	MODULE_INFO(test, "Y");
 #else
 #define kunit_test_suites_for_module(__suites)
 #endif /* MODULE */
diff --git a/lib/kunit/test.c b/lib/kunit/test.c
index a5053a07409f..8b11552dc215 100644
--- a/lib/kunit/test.c
+++ b/lib/kunit/test.c
@@ -11,6 +11,7 @@ 
 #include <kunit/test-bug.h>
 #include <linux/kernel.h>
 #include <linux/moduleparam.h>
+#include <linux/panic.h>
 #include <linux/sched/debug.h>
 #include <linux/sched.h>
 
@@ -501,6 +502,9 @@  int kunit_run_tests(struct kunit_suite *suite)
 	struct kunit_result_stats suite_stats = { 0 };
 	struct kunit_result_stats total_stats = { 0 };
 
+	/* Taint the kernel so we know we've run tests. */
+	add_taint(TAINT_TEST, LOCKDEP_STILL_OK);
+
 	if (suite->suite_init) {
 		suite->suite_init_err = suite->suite_init(suite);
 		if (suite->suite_init_err) {