On Thu, May 24, 2018 at 09:36:15AM -0500, Denis Kenzior wrote: > Hi Stephan, > > On 05/24/2018 12:57 AM, Stephan Mueller wrote: > > Am Donnerstag, 24. Mai 2018, 04:45:00 CEST schrieb Eric Biggers: > > > > Hi Eric, > > > > > > > > "Not having to rely on any third-party library" is not an excuse to add > > > random code to the kernel, which runs in a privileged context. Please do > > > PBKDF2 in userspace instead. > > > > I second that. Besides, if you really need to rely on the kernel crypto API to > > do that because you do not want to add yet another crypto lib, libkcapi has a > > PBKDF2 implementation that uses the kernel crypto API via AF_ALG. I.e. the > > kernel crypto API is used and yet the PBKDF logic is in user space. > > > > http://www.chronox.de/libkcapi.html > > > > I actually don't see why we _shouldn't_ have PBKDF in the kernel. We > already have at least 2 user space libraries that implement it via AF_ALG. > ell does this as well: > https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/pkcs5.c > > One can argue whether this is a good or bad idea, but the cat is out of the > bag. > > So from a practical perspective, would it not be better to make this an > explicit kernel API and not have userspace hammer AF_ALG socket a few > thousand times to do what it wants? > 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 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 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 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? [1] https://syzkaller.appspot.com/ [2] https://lkml.org/lkml/2016/3/31/1108 - Eric
