linux-kernel - Re: [PATCH v2] fscrypt: improve filename encryption and decryption performance

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]

Message-ID: <20250708182007.GB1255@sol>
Date: Tue, 8 Jul 2025 11:20:07 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: Yuwen Chen <ywen.chen@...mail.com>
Cc: davem@...emloft.net, herbert@...dor.apana.org.au, jaegeuk@...nel.org,
	linux-crypto@...r.kernel.org, linux-fscrypt@...r.kernel.org,
	linux-kernel@...r.kernel.org, tytso@....edu
Subject: Re: [PATCH v2] fscrypt: improve filename encryption and decryption
 performance

On Tue, Jul 08, 2025 at 03:33:34PM +0800, Yuwen Chen wrote:
> On Thu, 3 Jul 2025 22:14:41 -0700, Eric Biggers wrote:
> > I'm guessing you have some debugging options enabled in your kconfig.  Usually
> > the allocations aren't quite *that* expensive.  That being said, it's always
> > been really annoying that they have to be there.
> 
> Turn off most of the debugging options and merge these two patches
> for memory allocation. The performance test results are as follows:
> Before this submission was merged, when creating 10000 files,
> the performance test results are as follows:
> $ time /data/file_creater 10000
> 0m10.90s real     0m00.00s user     0m10.69s system
> 
> After merge these two patches, the performance is as follows:
> $ time /data/file_creater 10000
> 0m05.32s real     0m00.00s user     0m05.28s system
> 
> > Unfortunately, as far as I know, you actually can't just allocate the
> > skcipher_request on the stack like that, since the legacy crypto API assumes
> > that the request memory is DMA-able.  On-stack requests also might not be
> > properly aligned (see
> > https://lore.kernel.org/all/CA+55aFxJOzMim_d-O2E2yip8JWo0NdYs_72sNwFKSkTjy8q0Sw@mail.gmail.com/
> > -- may be outdated, but I haven't heard otherwise).
> 
> Thank you for the reminder. This should be a problem here.
> Just, why can SYNC_SKCIPHER_REQUEST_ON_STACK be allocated on
> the stack? Is it possible to use ALIGN to achieve alignment?

I suppose that in practice the request alignment only matters for the
off-CPU offloads, and that's how SYNC_SKCIPHER_REQUEST_ON_STACK gets
away with maybe not aligning the request reliably.  If you look at e.g.
the software AES-XTS code, it doesn't even use the request context at
all, which makes the entire exercise a bit pointless.

I'm thinking we should just go ahead and use sync_skcipher and
SYNC_SKCIPHER_REQUEST_ON_STACK for now.  Previously this was impossible
because the x86 accelerated AES-XTS algorithms had CRYPTO_ALG_ASYNC set,
but now it is possible.

Can you review and test the following patchset:
https://lore.kernel.org/linux-fscrypt/20250708181313.66961-1-ebiggers@kernel.org/ ?

- Eric