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

Date:   Tue, 18 Jul 2017 16:17:47 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
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 02:13:51PM +0800, Herbert Xu wrote:
> On Fri, Jun 30, 2017 at 05:27:34PM +0200, Richard Weinberger wrote:
> > Hi!
> > 
> > David and I faced a deadlock with switch_root when fscrypt was in use.
> > When /sbin/modprobe is encrypted using fscrypt and no other kernel component
> > requested an AES cipher before, first access to an encrypted file will trigger the
> > module_request() function, which will execute usermode helper /sbin/modprobe.
> > Is /sbin/modprobe also encrypted the kernel will deadlock because executing
> > it will again enter the module_request() path...
> > 
> > As workaround we currently do something like "ls /new_root > /dev/null" in our
> > initramfs to make request_module() happen before we change the root directory
> > to /new_root.
> > 
> > While this workaround is legit we think that this could be handled better.
> > Is there a way to request these ciphers before first usage? Herbert?
> > e.g. such that the filesystem can request them upon mount time.
> > 
> > Btw: This happens even when AES modules are builtins.
> 
> I think you're running into the problem because of templates, where
> the first instantiation will always be preceded by a request_module.
> 
> We should be able to fix this by doing two template probes instead
> of one.  So instead of the current order:
> 
> 1. Look up registered algorithms.
> 2. Request module.
> 3. Find templates (may request module).
> 
> We can do
> 
> 1. Look up registered algorithms.
> 2. Find templates without loading modules.
> 3. Request module.
> 4. Find templates (may request module).
> 

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.

Eric