linux-kernel - Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO

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: <CAK8P3a194XrKArryJbL+FQoza08xB3FOepyXxBxZAF7ChYkLZQ@mail.gmail.com>
Date:   Tue, 23 Feb 2021 21:40:29 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Randy Dunlap <rdunlap@...radead.org>
Cc:     Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky <leon@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Zhu Yanjun <zyjzyj2000@...il.com>,
        Julian Braha <julianbraha@...il.com>,
        Doug Ledford <dledford@...hat.com>,
        RDMA mailing list <linux-rdma@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drivers: infiniband: sw: rxe: fix kconfig dependency on CRYPTO

On Tue, Feb 23, 2021 at 9:36 PM Arnd Bergmann <arnd@...nel.org> wrote:
>
> For the specific case of CRC32, it might actually a good idea to change
> the code to call into the CRC32 code directly instead of the CRYPTO_CRC32
> abstraction. Would that work for RDMA_RXE?

On the more general question of whether a driver should 'select CRYPTO',
this is how it's currently done for the other users, but I don't
actually like this,
and in general recommend against force-enabling another subsystem when
a particular driver is enabled.

My preference would be to change all drivers that require crypto services
of some kind to use 'depends on CRYPTO' in combination with 'select CRYPTO_*',
as this is what we do for other cross-subsystem dependencies. However,
it seems unlikely that we can change it anytime soon, as the current method
is widespread and changing the dependencies would break users that do
'make oldconfig' on an old configuration.

       Arnd