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: <CAG_fn=UcWy+gbYLDM2WQZ=BZuVRML17KJ0L+=zsSg7+yDo4oGA@mail.gmail.com>
Date:   Wed, 7 Sep 2022 11:18:24 +0200
From:   Alexander Potapenko <glider@...gle.com>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Linux Crypto List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Robert Elliott <elliott@....com>
Subject: Re: linux-next: manual merge of the mm tree with the crypto tree

On Wed, Sep 7, 2022 at 12:12 AM Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Tue, Sep 06, 2022 at 08:20:17PM +1000, Stephen Rothwell wrote:
> > diff --git a/arch/x86/crypto/Kconfig b/arch/x86/crypto/Kconfig
> > index 9bb0f7939c6b..856f5d8ca65f 100644
> > --- a/arch/x86/crypto/Kconfig
> > +++ b/arch/x86/crypto/Kconfig
> > @@ -5,6 +5,7 @@ menu "Accelerated Cryptographic Algorithms for CPU (x86)"
> >  config CRYPTO_CURVE25519_X86
> >       tristate "Public key crypto: Curve25519 (ADX)"
> >       depends on X86 && 64BIT
> > +     depends on !KMSAN # avoid false positives from assembly
> >       select CRYPTO_LIB_CURVE25519_GENERIC
> >       select CRYPTO_ARCH_HAVE_LIB_CURVE25519
> >       help
> > @@ -16,6 +17,7 @@ config CRYPTO_CURVE25519_X86
> >  config CRYPTO_AES_NI_INTEL
> >       tristate "Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTR, XTS, GCM (AES-NI)"
> >       depends on X86
> > +     depends on !KMSAN # avoid false positives from assembly
> >       select CRYPTO_AEAD
> >       select CRYPTO_LIB_AES
> >       select CRYPTO_ALGAPI
> > @@ -32,6 +34,7 @@ config CRYPTO_AES_NI_INTEL
> >  config CRYPTO_BLOWFISH_X86_64
> >       tristate "Ciphers: Blowfish, modes: ECB, CBC"
> >       depends on X86 && 64BIT
> > +     depends on !KMSAN # avoid false positives from assembly
> >       select CRYPTO_SKCIPHER
> >       select CRYPTO_BLOWFISH_COMMON
> >       imply CRYPTO_CTR
> > @@ -44,6 +47,7 @@ config CRYPTO_BLOWFISH_X86_64
> >  config CRYPTO_CAMELLIA_X86_64
> >       tristate "Ciphers: Camellia with modes: ECB, CBC"
> >       depends on X86 && 64BIT
> > +     depends on !KMSAN # avoid false positives from assembly
> >       select CRYPTO_SKCIPHER
> >       imply CRYPTO_CTR
> >       help
> > @@ -55,6 +59,7 @@ config CRYPTO_CAMELLIA_X86_64
> >  config CRYPTO_CAMELLIA_AESNI_AVX_X86_64
> >       tristate "Ciphers: Camellia with modes: ECB, CBC (AES-NI/AVX)"
> >       depends on X86 && 64BIT
> > +     depends on !KMSAN # avoid false positives from assembly
> >       select CRYPTO_SKCIPHER
> >       select CRYPTO_CAMELLIA_X86_64
> >       select CRYPTO_SIMD
>
> Are there any options in arch/x86/crypto/Kconfig that *don't* need a dependency
> on !KMSAN?  If not, this could be done in a much simpler way.

Am I understanding right that arch/x86/crypto is supposed to contain
algorithms implemented in x86 assembly rather than plain C?
If so, we should definitely disable all of them under KMSAN to avoid
false positives. And, yes, in a simpler way :)

What's the best way to handle this? Send another patch series? Or
maybe just an update for "crypto: kmsan: disable accelerated configs
under KMSAN"?

> - Eric



-- 
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ