linux-kernel - Re: [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies

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]

Date:   Wed, 14 Sep 2022 10:18:22 +0200
From:   Alexander Potapenko <glider@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Eric Biggers <ebiggers@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Robert Elliott <elliott@....com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Crypto List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-next <linux-next@...r.kernel.org>
Subject: Re: [PATCH -next 1/2] x86: crypto: kmsan: revert !KMSAN dependencies

On Wed, Sep 14, 2022 at 2:52 AM Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Fri,  9 Sep 2022 11:58:10 +0200 Alexander Potapenko <glider@...gle.com> wrote:
>
> > This patch reverts "crypto: Kconfig: fix up for "crypto: kmsan: disable
> > accelerated configs under KMSAN" used by Stephen Rothwell to cleanly
> > merge KMSAN patches into linux-next.
> >
> > Because now arch-specific crypto configs reside in a separate Kconfig
> > file, we can disable them all by adding a single !KMSAN before including
> > that file (done in the following patch).
> >
> > Among others, this patch reverts !KMSAN check for
> > CONFIG_CRYPTO_AEGIS128_SIMD, which is ARM-only and is hence unnecessary,
> > because KMSAN does not support ARM yet.
>
> As I understand it, these patches are against linux-next and only
> linux-next because they pertain to linux-next's resolution of conflicts
> between the MM tree and the crypto tree?

The thing is that this patch only makes sense with its counterpart
that adds a !KMSAN condition on "source arch/x86/crypto/Kconfig", and
the latter file is missing in the -mm tree.

> I'm not sure how to handle that, even if anyone wants to.  How about
> you send an update to
> git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm's mm-unstable
> branch so the code which is there makes sense?  Then we'll ask Stephen
> to redo the crypto tree resolution?

Because the crypto tree is moving code crypto/Kconfig to
arch/x86/crypto/Kconfig, we'll still need to apply these two patches
to the result of the crypto tree merge.

I was going to send out the updated patch series anyway (there are
minor improvements to the core which let us drop "kmsan: unpoison @tlb
in arch_tlb_gather_mmu()", also there's a new test case).
I could drop "crypto: kmsan: disable accelerated configs under KMSAN"
from it, so that it would be possible to enable accelerated configs
under KMSAN at the cost of false positives (which are only visible if
one builds with KMSAN).
Then, once arch/x86/crypto/Kconfig hits -mm, I can send the remaining
patch that disables accelerated crypto under KMSAN:
https://lore.kernel.org/all/20220909095811.2166073-2-glider@google.com/

Or I could just send v7 patches against mm-unstable and ask Stephen to
apply both https://lore.kernel.org/all/20220909095811.2166073-2-glider@google.com/
and https://lore.kernel.org/all/20220909095811.2166073-2-glider@google.com/
at merge time.

Which option is better?

--
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg