Hi Denis, On Fri, May 25, 2018 at 09:48:36AM -0500, Denis Kenzior wrote: > 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? I've explained this already -- it is exactly the *opposite* of good security practice to increase the attack surface of ring 0 code. Have *you* actually thought about how it ridiculous it is elevate privileges just to do math? We need to be reducing the kernel attack surface, not increasing it. It's great that you're confident in me, Herbert, Stephen, and other people who contribute to the Linux crypto API. The reality though is that there are still known denial of service vulnerabilities that no one has found time to fix yet, like deadlocking the kernel through recursive pcrypt, or exhausting kernel memory by instantiating an unbounded number of crypto algorithms. These types of bugs aren't relevant for userspace crypto libraries as it would just be an application shooting itself in the foot, but in the kernel they are a problem for everyone, at least without e.g. an SELinux policy in place to lock down the attack surface. Again, all your arguments minus the crypto-specific parts also apply to sys_leftpad(), which to be very clear was an April Fool's joke, and not an actual proposal. I trust that this wasn't meant to be a very late April Fool's joke too :-) > > > > > 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 :) > No, it's exactly why people should *not* want to do crypto in the kernel, because that class of bug cannot exist in userspace code. Eric
