Page MenuHomeFreeBSD

blake2: Remove dieing flag and rw lock
ClosedPublic

Authored by jhb on Aug 24 2023, 4:23 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 6:02 AM
Unknown Object (File)
Mon, Oct 21, 7:34 AM
Unknown Object (File)
Sun, Oct 20, 11:26 PM
Unknown Object (File)
Sun, Oct 20, 11:26 PM
Unknown Object (File)
Sun, Oct 20, 11:26 PM
Unknown Object (File)
Fri, Oct 18, 6:51 PM
Unknown Object (File)
Oct 2 2024, 11:38 AM
Unknown Object (File)
Oct 1 2024, 7:43 AM
Subscribers

Details

Summary

crypto_unregister_all already disables new sessions and waits for
existing sessions to be destroyed before returning.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 53274
Build 50165: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Aug 24 2023, 4:23 PM

BTW, given that Wireguard doesn't use OCF for blake2, I wonder if we might not want to just axe this driver and associated code entirely? Maybe we could hook the SSE variants of blake2 that this driver uses up to the library interface that Wireguard actually uses, but it's still not clear to me that blake2 is used enough in wg(4) for that to be worth it.

This revision is now accepted and ready to land.Aug 24 2023, 4:41 PM
In D41581#947582, @jhb wrote:

BTW, given that Wireguard doesn't use OCF for blake2, I wonder if we might not want to just axe this driver and associated code entirely? Maybe we could hook the SSE variants of blake2 that this driver uses up to the library interface that Wireguard actually uses, but it's still not clear to me that blake2 is used enough in wg(4) for that to be worth it.

Per the log from the original commit, the motivation for adding this driver was to simplify testing via userspace, with cryptocheck etc.. For that reason alone I'd be inclined to keep this.

In D41581#947582, @jhb wrote:

BTW, given that Wireguard doesn't use OCF for blake2, I wonder if we might not want to just axe this driver and associated code entirely? Maybe we could hook the SSE variants of blake2 that this driver uses up to the library interface that Wireguard actually uses, but it's still not clear to me that blake2 is used enough in wg(4) for that to be worth it.

Per the log from the original commit, the motivation for adding this driver was to simplify testing via userspace, with cryptocheck etc.. For that reason alone I'd be inclined to keep this.

The only thing is there is no other consumer besides /dev/crypto, and only if you set kern.crypto.allow_soft=1 (which is really only there for cryptocheck). None of GELI or IPsec, etc. use the Blake2 algorithms at all, only wg(4), and wg(4) doesn't use OCF for Blake2.

In D41581#947709, @jhb wrote:
In D41581#947582, @jhb wrote:

BTW, given that Wireguard doesn't use OCF for blake2, I wonder if we might not want to just axe this driver and associated code entirely? Maybe we could hook the SSE variants of blake2 that this driver uses up to the library interface that Wireguard actually uses, but it's still not clear to me that blake2 is used enough in wg(4) for that to be worth it.

Per the log from the original commit, the motivation for adding this driver was to simplify testing via userspace, with cryptocheck etc.. For that reason alone I'd be inclined to keep this.

The only thing is there is no other consumer besides /dev/crypto, and only if you set kern.crypto.allow_soft=1 (which is really only there for cryptocheck). None of GELI or IPsec, etc. use the Blake2 algorithms at all, only wg(4), and wg(4) doesn't use OCF for Blake2.

Right, but isn't it useful to be able to verify the backend using cryptocheck? This driver isn't exactly a lot of code to maintain.

I don't have any particular objection to removing this driver, I just don't think it's useless.

This revision was automatically updated to reflect the committed changes.