| Message ID | 20220708044847.531566-3-davidgow@google.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c272612cb4a2f7cde550d35f46cde159a2af0bab |
| Delegated to: | Brendan Higgins |
| Headers | show |
| Series | [v6,1/4] panic: Taint kernel if tests are run | expand |
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
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
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
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
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
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 --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) {