Hi Eric,
The solution to the "too many system calls" problem is trivial: just do SHA-512
in userspace. It's just math; you don't need a system call, any more than you
would call sys_add(1, 1) to compute 1 + 1. The CPU instructions that can
accelerate SHA-512, such as AVX and ARM CE, are available in userspace too; and
there are tons of libraries already available that implement it for you. Your
argument isn't fundamentally different from saying that sys_leftpad() (if we had
the extraordinary misfortune of it actually existing) is too slow, so we should
add a Javascript interpreter to the kernel.
So lets recap. The Kernel crypto framework is something that:
a) (some, many?) people are totally happy with, it does everything that
they want
b) is peer reviewed by the best programmers in the world
c) responds / fixes vulnerabilities almost instantly
d) automatically picks the best software optimized version of a given
crypto algorithm for us
e) automagically uses hardware optimization if the system supports it
f) API compatibility is essentially guaranteed forever
g) Maybe not the most performant in the world, but to many users this
doesn't matter.
So your response to those users is to please stop using what works well
and start adding random crypto code from the internet into their
project? Something that likely won't do a, b, c, d, e or f above just
because *oh gosh* we might find and have to fix some bugs in the kernel?
Have you actually thought through how that sounds?
What you call laziness I call 'common sense' and 'good security
practice.' Does using the kernel make sense for everyone? No. But for
some it does. So if there's a legitimate way to make things better, can
we not discuss them civilly?
Also note that in the rare cases where the kernel actually does do very long
running calculations for whatever reason, kernel developers pretty regularly
screw it up by forgetting to insert explicit preemption points (cond_resched()),
or (slightly less bad) making it noninterruptible. I had to "fix" one of these,
where someone for whatever reason added a keyctl() operation that does
Diffie-Hellman key exchange in software. In !CONFIG_PREEMPT kernels any
unprivileged user could call it to lock up all CPUs for 20+ seconds, meaning
that no other processes can be scheduled on them. This isn't a problem at all
in userspace.
And this is exactly why people should _want_ to use the kernel crypto
framework. Because people like you exist and fix such issues. So
again, kudos :)
Regards,
-Denis
