Here is a reply from linux-crypto. Among other things:
Your patch description is also missing any mention of crypto accelerator hardware. Quite a bit of the complexity in the (kernel) crypto API, such as scatterlist support and asynchronous execution, exists because it supports crypto accelerators. AFAICS your new APIs cannot support crypto accelerators, as your APIs are synchronous and operate on virtual addresses. I assume your justification is that “djb algorithms” like ChaCha and Poly1305 don’t need crypto accelerators as they are fast in software. But you never explicitly stated this and discussed the tradeoffs. Since this is basically the foundation for the design you’ve chosen, it really needs to be addressed.
I’ve had enough code reviews and read enough LKML threads to appreciate Eric Biggers critiques of the code. Let’s hope that all parties rapidly converge to code they are happy with and merge it in!
Be nice if crypto authors would spend less time explaining how simple, clean, and easy to use their apis are, and more time explaining the APIs and providing examples.
It seems like you may not recognize the author. I would typically agree with you on first glance, but given who it is and what it is I wouldn’t be surprised if it got merged.
Where’d we get this trend of libraries self-described as “minimal”? Is there even a definition of what that means? If a library exposes 100 functions, but they’re all used, is that “minimal”? Wouldn’t it be better to have a library described as “Everything you need to solve X without filling in the gaps yourself”? Reminds me of “light” food… after all of human history desperately looking for calories, suddenly having *less” calories is the main selling point – “fat free half and half” being the worst example.
There is also an explanation in the email on why it is useful to have a minimal crypto library in the kernel. In short, you mostly don’t need flexible APIs when in kernel. That might be different in userland.
Here is a reply from linux-crypto. Among other things:
I’ve had enough code reviews and read enough LKML threads to appreciate Eric Biggers critiques of the code. Let’s hope that all parties rapidly converge to code they are happy with and merge it in!
Be nice if crypto authors would spend less time explaining how simple, clean, and easy to use their apis are, and more time explaining the APIs and providing examples.
There is no way in heck that linus will merge some DIY home rolled crypto code into the kernel
It seems like you may not recognize the author. I would typically agree with you on first glance, but given who it is and what it is I wouldn’t be surprised if it got merged.
That’s a good point but missing key detail. I’ll add author did WireGuard which has had good results in both formal verification and code review.
Where else is kernel crypto code rolled?
By Intel, Red Hat, IBM, or a few others
Ahem… http://lists.openwall.net/netdev/2018/08/02/124
High praise from linus!
Why not? How would Linus even know if some crypto code was DIY nonsense?
(The subtext of these commits from Jason is that the existing kernel crypto APIs are not particularly good, IMO.)
Where’d we get this trend of libraries self-described as “minimal”? Is there even a definition of what that means? If a library exposes 100 functions, but they’re all used, is that “minimal”? Wouldn’t it be better to have a library described as “Everything you need to solve X without filling in the gaps yourself”? Reminds me of “light” food… after all of human history desperately looking for calories, suddenly having *less” calories is the main selling point – “fat free half and half” being the worst example.
Code is different from food. Code is liability.
There is also an explanation in the email on why it is useful to have a minimal crypto library in the kernel. In short, you mostly don’t need flexible APIs when in kernel. That might be different in userland.