linux-kernel - Re: [PATCH v2 3/6] crypto: x86/chacha20 - limit the preemption-disabled section

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <acad781e9981c49b83b6dfdc8cefed6246df469a.camel@strongswan.org>
Date:   Sun, 02 Dec 2018 11:47:42 +0100
From:   Martin Willi <martin@...ongswan.org>
To:     Eric Biggers <ebiggers@...nel.org>, linux-crypto@...r.kernel.org
Cc:     Paul Crowley <paulcrowley@...gle.com>,
        Milan Broz <gmazyland@...il.com>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/6] crypto: x86/chacha20 - limit the
 preemption-disabled section

> To improve responsiveness, disable preemption for each step of the
> walk (which is at most PAGE_SIZE) rather than for the entire
> encryption/decryption operation.

It seems that it is not that uncommon for IPsec to get small inputs
scattered over multiple blocks. Doing FPU context saving for each walk
step then can slow down things.

An alternative approach could be to re-enable preemption not based on
the walk steps, but on the amount of bytes processed. This would
satisfy both users, I guess.

In the long run we probably need a better approach for FPU context
saving, as this really hurts performance-wise. For IPsec we should find
a way to avoid the (multiple) per-packet FPU save/restores in softirq
context, but I guess this requires support from process context
switching.

Best regards
Martin