random: remove safe(4)

[obrien]

Summary

The SafeNet SafeXcel 1141/1741 crypto accelerator only supports
deprecated & disallowed algorithms (NIST SP800-224idp): DES,
Triple-DES, MD5, SHA-1, SHA1-HMAC, and non-SP800-90B RNG.

Only the AES functionality is still NIST allowed. However,
modern CPU's have higher software AES throughput than this
25 year old crypto accelerator.

[obrien]

tags

[obrien]

I could only find PCI cards with this chipset (SafeXcel 140-PCI, SafeXcel 141-PCI, SafeXcel 171-PCI, and SafeXcel 241-PCI), nothing newer to plug into a modern AMD64 system. I haven't yet found any(which) SoC's may have the SafeXcel embedded, but I doubt they are 64-bit capable.

[cem]

Hm, not sure I'd call AES deprecated or disallowed. But no objection to removing.

[cem]

sys/sys/random.h

93

I think this is an ABI change, and requires the usual ABI bump machinery / caution.

[obrien]

PBKAC

[obrien]

add more files

[ziaee]

Can we please do driver removals in a measured way, with a mail to an appropriate list issuing a schedule for deprecation and removal, and an entry in the release notes?

To be clear, I don't use/want this hardware and actually it's really ugly in the hardware release notes. I've tried rewriting the entry to fix it and failed, even.

[obrien]

embelish

[obrien]

update log message

[obrien]

In D53181#1214931, @cem wrote:

Hm, not sure I'd call AES deprecated or disallowed. But no objection to removing.

I've updated the log message to not claim AES is deprecated. I've added my opinion on why we should still GC safe(4) for even AES use.

[jhb]

I already trimmed most of the algorithms from this driver after dropping several deprecated IPsec algorithms back in 2020. We still support AES-CBC with a SHA1 HMAC for crufty IPsec setups (and in particular, when I last purged IPsec algorithms based on RFC 8221, that combination was not disallowed) and geli(4).

There is a newer RFC 9395 (published April 2023) which deprecate SHA1 HMAC for IPsec, so we could consider adopting that in 16, but we would need to add warnings, etc. If we wanted to deprecate it from geli(4) that would also need warnings, etc. I did this for MD5-HMAC before (rG5c420aae3b18027809507dc9142182d4290897bf). Kerberos has not yet deprecated SHA1 it would seem (RFC 8429 remains the newest RFC there).

sys/conf/options

739

hifi(4) is also of dubious usefulness

sys/sys/random.h

93

Is it private to the kernel? OCTEON is also no longer present (was MIPS only) so should perhaps be removed as well, or if it is a user-facing ABI, just leave the value here as a placeholder.

[obrien]

sys/conf/options

739

Already posted as https://reviews.freebsd.org/D53182

sys/sys/random.h

93

Already posted as https://reviews.freebsd.org/D53146

[obrien]

One thing specific to safe(4) is, does SafeXcel 1141/1741 cards / SoC's exist that would plug into any of the platforms listed on https://www.freebsd.org/platforms for 15.0?
I can't find any PCI-e (or even PCI), or USB cards with this HW one can buy. I question how wide-spread safe(4) ever was. I cannot figure out how Global Technology Associates, Inc. used this.
Even on eBay, in both current and completed auctions, there is only https://www.ebay.com/itm/365919401957 - which are just silicon chips from 2005.

[jhb]

BTW, for both hifn(4) and safe(4), please first do a commit to add a deprecation warning using the gone_in(9) API and merge that down to the stable/14 and stable/15 branches. We also do deprecation warnings in manpages in addition to gone_in(9).