Re: retire hifn safe ubsec
On 2021/10/21 10:02, Theo de Raadt wrote: > Stuart Henderson 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.
Re: retire hifn safe ubsec
Stuart Henderson 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. 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.
Re: retire hifn safe ubsec
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.
Re: retire hifn safe ubsec
On Thu, Oct 21, 2021 at 04:30:02PM +0200, 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) ? > Agreed, I see little benefit in having them around now. -- :wq Claudio
Re: retire hifn safe ubsec
On Thu, Oct 21, 2021 at 04:30:02PM +0200, Alexander Bluhm wrote: > 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) ? I am OK with the removal of these drivers. Some manual pages, sysctl.2, pci.4 and ipsec.conf.5, now contain stale references. Also, the removed manual pages are still linked in share/man/man4/Makefile.
