On 2021/10/21 10:02, Theo de Raadt wrote: > Stuart Henderson <s...@spacehopper.org> wrote: > > > On 2021/10/21 16:30, Alexander Bluhm wrote: > > > Hi, > > > > > > Goal is to retire the async crypto API. It is slow and adds > > > complexity which hinders MP progress in IPsec. It is used by the > > > old PCI devices hifn(4), safe(4), and ubsec(4). > > > > > > These devices are not common anymore. Using the CPU for crypto is > > > faster than offloading via the PCI bus. By having special requirements > > > for the crypto API, those devices slow down modern machines. They > > > only support crypto algorithms that are insecure nowadays. > > > > > > ok to remove hifn(4) safe(4) ubsec(4) ? > > > > OK. The main useful feature as far as I'm concerned is the rng but > > I don't think it's useful/common enough to be worth doing anything other > > than just deleting the drivers. > > Perhaps that function can be left intact in a few drivers.
I think it's not really worthwhile. From memory and a bit of a trawl in dmesglog the main use of these with OpenBSD has been is hifn on Soekris net45xx/48xx. (There might have been some on PCEngines WRAP but those were minipci only and the minipci hifn was much less common). > But honestly I think the software rng stack we have now does sufficient > amounts of churn, and I cannot see runtime operations which exhaust it. > Send or receive packets? You are generating interrupts at unpredictable > interrupt time deltas, those get folded in. This isn't a basic fold like > in other systems, it is powerful & sophisticated and I see no way it can > fall behind. Exactly. I'm definitely OK with them going, just wanted to consider possible use cases first.
