linux-kernel - Re: fscrypt request

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] [day] [month] [year] [list]

Date:   Wed, 19 Jul 2017 12:58:52 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Eric Biggers <ebiggers3@...il.com>
Cc:     Richard Weinberger <richard@....at>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-fscrypt@...r.kernel.org, David Gstir <david@...ma-star.at>
Subject: Re: fscrypt request_module() deadlock

On Tue, Jul 18, 2017 at 04:17:47PM -0700, Eric Biggers wrote:
> 
> While that should solve the problem, isn't it possible to actually have a module
> which supplies an algorithm like "xts(aes)"?  In that case it wouldn't be
> desirable to instantiate the generic "xts" template.

Well, in the case where only xts and aes are built into the kernel
I think we have to use that instead of going to request_module as
otherwise we cannot avoid the dead-lock that is the subject of this
discussion.

If you want accelerated xts(aes) to work while building generic xts
and aes into the kernel then you should also build the accelerated
xts(aes) into the kernel (or load the manually once modules can be
loaded).

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt