linux-kernel - Re: [PATCH] xtensa: enable KCSAN

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMo8BfLANCoLa4zXO4aYmX0Wk7fV7_wei04MveLHu=d2RDZ77w@mail.gmail.com>
Date:   Wed, 20 Apr 2022 11:11:14 -0700
From:   Max Filippov <jcmvbkbc@...il.com>
To:     Marco Elver <elver@...gle.com>
Cc:     "open list:TENSILICA XTENSA PORT (xtensa)" 
        <linux-xtensa@...ux-xtensa.org>, Chris Zankel <chris@...kel.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com
Subject: Re: [PATCH] xtensa: enable KCSAN

On Wed, Apr 20, 2022 at 2:04 AM Marco Elver <elver@...gle.com> wrote:
> So the right thing to do might be to implement the builtin atomics using
> the kernel's atomic64_* primitives. However, granted, the builtin
> atomics might not be needed on xtensa (depending on configuration).
> Their existence is due to some compiler instrumentation emitting
> builtin-atomics (Clang's GCOV), folks using them accidentally and
> blaming KCSAN (also https://paulmck.livejournal.com/64970.html).
>
> So I think it's fair to leave them to BUG() until somebody complains (at
> which point they need to be implemented). I leave it to you.

Sure, that was my plan.

> > > Did the kcsan_test pass?
> >
> > current results are the following on QEMU:
> >
> >      # test_missing_barrier: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1313
> >      Expected match_expect to be true, but is false
> >      # test_atomic_builtins_missing_barrier: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1356
> >      Expected match_expect to be true, but is false
> >  # kcsan: pass:27 fail:2 skip:0 total:29
> >  # Totals: pass:193 fail:4 skip:0 total:197
> >
> > and the following on the real hardware:
> >
> >     # test_concurrent_races: EXPECTATION FAILED at kernel/kcsan/kcsan_test.c:762
> >     Expected match_expect to be true, but is false
> >     # test_write_write_struct_part: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:910
> >     Expected match_expect to be true, but is false
> >     # test_assert_exclusive_access_writer: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1077
> >     Expected match_expect_access_writer to be true, but is false
> >     # test_assert_exclusive_bits_change: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1098
> >     Expected match_expect to be true, but is false
> >     # test_assert_exclusive_writer_scoped: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1136
> >     Expected match_expect_start to be true, but is false
> >     # test_missing_barrier: EXPECTATION FAILED at kernel/kcsan/kcsan_test.c:1313
> >     Expected match_expect to be true, but is false
> >     # test_atomic_builtins_missing_barrier: EXPECTATION FAILED at
> > kernel/kcsan/kcsan_test.c:1356
> >     Expected match_expect to be true, but is false
> > # kcsan: pass:22 fail:7 skip:0 total:29
> > # Totals: pass:177 fail:20 skip:0 total:197
>
> Each test case is run with varying number of threads - am I correctly
> inferring that out of all test cases, usually only one such run failed,
> and runs with different number of threads (of the same test case)
> succeeded?

For most of the failures -- yes.
For the test_missing_barrier and test_atomic_builtins_missing_barrier
on the hardware it was the opposite: only one subtest succeeded while
all others failed. Does it mean that the xtensa memory model is
insufficiently weak?

> If that's the case, I think we can say that it works, and the failures
> are due to flakiness with either higher or lower threads counts. I know
> that some test cases might still be flaky under QEMU TCG because of how
> it does concurrent execution of different CPU cores.

Thanks for taking a look.
I'll post v2 with a couple additional minor changes.

-- 
Thanks.
-- Max