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: <76e055e9-5b2b-75b9-b545-cbdbc6ad2112@scottdial.com>
Date: Thu, 24 Aug 2023 13:08:41 -0400
From: Scott Dial <scott@...ttdial.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
 Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next] macsec: introduce default_async_crypto sysctl

On 8/24/2023 9:01 AM, Sabrina Dubroca wrote:
> 2023-08-23, 16:22:31 -0400, Scott Dial wrote:
>> AES-NI's implementation of gcm(aes) requires the FPU, so if it's busy the
>> decrypt gets stuck on the cryptd queue, but that queue is not
>> order-preserving.
> 
> It should be (per CPU [*]). The queue itself is a linked list, and if we
> have requests on the queue we don't let new requests skip the queue.

My apologies, I'll be the first to admit that I have not tracked all of 
the code changes to either the macsec driver or linux-crypto since I 
first made the commit. This comment that requests are queued forced me 
to review the code again and it appears that the queueing issue was 
resolved in v5.2-rc1 with commit 1661131a0479, so I no longer believe we 
need the CRYPTO_ALG_ASYNC since v5.2 and going forward.

So, I believe my patch should be reverted from the mainline kernel and 
any releases that are still getting maintenance releases -- I believe 
v5.4, v5.10, v5.15, and v6.1.

-- 
Scott Dial
scott@...ttdial.com


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ