| 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
| ||
|
Message-ID: <CACT4Y+YtpOUHBrdd5n2ajueMreh4Bz8uvR9NXU50=mNQD9-OEw@mail.gmail.com>
Date: Tue, 31 Mar 2020 09:48:48 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Patricia Alfonso <trishalfonso@...gle.com>
Cc: Alan Maguire <alan.maguire@...cle.com>,
David Gow <davidgow@...gle.com>,
Brendan Higgins <brendanhiggins@...gle.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
LKML <linux-kernel@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>,
kunit-dev@...glegroups.com,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>
Subject: Re: [RFC PATCH v2 1/3] Add KUnit Struct to Current Task
On Mon, Mar 30, 2020 at 9:30 PM Patricia Alfonso
<trishalfonso@...gle.com> wrote:
>
> On Wed, Mar 25, 2020 at 12:00 PM Patricia Alfonso
> <trishalfonso@...gle.com> wrote:
> >
> > On Wed, Mar 25, 2020 at 5:42 AM Alan Maguire <alan.maguire@...cle.com> wrote:
> > >
> > >
> > > On Tue, 24 Mar 2020, Patricia Alfonso wrote:
> > >
> > > > On Tue, Mar 24, 2020 at 9:40 AM Alan Maguire <alan.maguire@...cle.com> wrote:
> > > > >
> > > > >
> > > > > On Thu, 19 Mar 2020, Patricia Alfonso wrote:
> > > > >
> > > > > > In order to integrate debugging tools like KASAN into the KUnit
> > > > > > framework, add KUnit struct to the current task to keep track of the
> > > > > > current KUnit test.
> > > > > >
> > > > > > Signed-off-by: Patricia Alfonso <trishalfonso@...gle.com>
> > > > > > ---
> > > > > > include/linux/sched.h | 4 ++++
> > > > > > 1 file changed, 4 insertions(+)
> > > > > >
> > > > > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > > > > index 04278493bf15..1fbfa0634776 100644
> > > > > > --- a/include/linux/sched.h
> > > > > > +++ b/include/linux/sched.h
> > > > > > @@ -1180,6 +1180,10 @@ struct task_struct {
> > > > > > unsigned int kasan_depth;
> > > > > > #endif
> > > > > >
> > > > > > +#if IS_BUILTIN(CONFIG_KUNIT)
> > > > >
> > > > > This patch set looks great! You might have noticed I
> > > > > refreshed the kunit resources stuff to incorporate
> > > > > feedback from Brendan, but I don't think any API changes
> > > > > were made that should have consequences for your code
> > > > > (I'm building with your patches on top to make sure).
> > > > > I'd suggest promoting from RFC to v3 on the next round
> > > > > unless anyone objects.
> > > > >
> > > > > As Dmitry suggested, the above could likely be changed to be
> > > > > "#ifdef CONFIG_KUNIT" as kunit can be built as a
> > > > > module also. More on this in patch 2..
> > > > >
> > > > I suppose this could be changed so that this can be used in possible
> > > > future scenarios, but for now, since built-in things can't rely on
> > > > modules, the KASAN integration relies on KUnit being built-in.
> > > >
> > >
> > > I think we can get around that. I've tried tweaking the resources
> > > patchset such that the functions you need in KASAN (which
> > > is builtin) are declared as "static inline" in include/kunit/test.h;
> > > doing this allows us to build kunit and test_kasan as a
> > > module while supporting the builtin functionality required to
> > > retrieve and use kunit resources within KASAN itself.
> > >
> > Okay, great!
> >
> > > The impact of this amounts to a few functions, but it would
> > > require a rebase of your changes. I'll send out a v3 of the
> > > resources patches shortly; I just want to do some additional
> > > testing on them. I can also send you the modified versions of
> > > your patches that I used to test with.
> > >
> > That sounds good.
> >
> > > With these changes I can run the tests on baremetal
> > > x86_64 by modprobe'ing test_kasan. However I see a few failures:
> > >
> > > [ 87.577012] # kasan_memchr: EXPECTATION FAILED at lib/test_kasan.c:509
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.577104] not ok 30 - kasan_memchr
> > > [ 87.603823] # kasan_memcmp: EXPECTATION FAILED at lib/test_kasan.c:523
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.603929] not ok 31 - kasan_memcmp
> > > [ 87.630644] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:544
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.630910] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:546
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.654037] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:548
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.677179] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:550
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.700242] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:552
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.723336] # kasan_strings: EXPECTATION FAILED at
> > > lib/test_kasan.c:554
> > > Expected kasan_data->report_expected == kasan_data->report_found,
> > > but
> > > kasan_data->report_expected == 1
> > > kasan_data->report_found == 0
> > > [ 87.746304] not ok 32 - kasan_strings
> > >
> > > The above three tests consistently fail while everything
> > > else passes, and happen irrespective of whether kunit
> > > is built as a module or built-in. Let me know if you
> > > need any more info to debug (I built the kernel with
> > > CONFIG_SLUB=y if that matters).
> > >
> > Unfortunately, I have not been able to replicate this issue and I
> > don't have a clue why these specific tests would fail with a different
> > configuration. I've tried running these tests on UML with KUnit
> > built-in with SLUB=y and SLAB=y, and I've done the same in x86_64. Let
> > me know if there's anything else that could help me debug this myself.
> >
> Alan sent me the .config and I was able to replicate the test failures
> found above. I traced the problem config to CONFIG_AMD_MEM_ENCRYPT=y.
> The interesting part is that I ran the original test module with this
> config enabled and the same tests failed there too. I wonder if this
> is an expected failure or something in the test that is causing this
> problem?
This is:
https://bugzilla.kernel.org/show_bug.cgi?id=206337
I think we should add:
// See https://bugzilla.kernel.org/show_bug.cgi?id=206337
if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
return;
Powered by blists - more mailing lists