Hi Eric,
No, we don't add random code to the kernel just because people are lazy. IMO it was a mistake that AF_ALG allows access to software crypto implementations by default (as opposed to just hardware crypto devices), but it's not an excuse to
I understand, but my point is, AF_ALG is out there now and hand-wringing about how it is a bad idea is sort of late / misplaced...
add random other stuff to the kernel. The kernel runs in a privileged context under special constraints, e.g. non-preemptible in some configurations, and any bug can crash or lock up the system, leak data, or even allow elevation of privilege. We're already dealing with hundreds of bugs in the kernel found by fuzzing [1], many of which no one feels very responsible for fixing. In fact
I can only speak for myself here, but yes, this is understood. And I still disagree with your assessment.
about 20 bugs were reported in AF_ALG as soon as definitions for AF_ALG were added to syzkaller; at least a couple were very likely exploitable to gain
And I saw your contributions fly by to fix a lot of these issues. Given that our project depends on and heavily uses AF_ALG, this is really much appreciated!
arbitrary kernel code execution. The last thing we need is adding even more code to the kernel just because people are too lazy to write userspace code. Do we need sys_leftpad() [2] next?
Well, I'm not sure where the laziness comment is coming from. We have at least two user-space implementations that implement PBKDF on top of AF_ALG. But a typical invocation of PBKDF runs a couple of thousand iterations. That is a lot of system call overhead. Would it not be better to fix things to be more efficient rather than worry about how 'mistakes were made'?
And yes, people can always try to take things too far (as you point out in [2]), but I would argue this isn't such a bad one.
Regards, -Denis
