Hi Denis, On Thu, May 24, 2018 at 07:56:50PM -0500, Denis Kenzior wrote: > Hi Ted, > > > > I'm not really here to criticize or judge the past. AF_ALG exists now. It > > > is being used. Can we just make it better? Or are we going to whinge at > > > every user that tries to use (and improve) kernel features that (some) > > > people disagree with because it can 'compromise' kernel security? > > > > Another point of view is that it was arguably a mistake, and we > > shouldn't make it worse. > > Fair enough. I'm just voicing the opposite point of view. Namely that you > have created something nice, and useful. Even if it turned out not quite > like you thought it would be in hindsight. > > > > > > > Also, if speed isn't a worry, why not just a single software-only > > > > implementation of SHA1, and be done with it? It's what I did in > > > > e2fsprogs for e4crypt. > > > > > > If things were that simple, we would definitely not be having this exchange. > > > Lets just say we use just about every feature that crypto subsystem provides > > > in some way. > > > > What I'm saying here is if you need to code PBPDF2 in user-space, it > > _really_ isn't hard. I've done it. It's less than 7k of source code > > to implement SHA512: > > > > https://ghit.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/ext2fs/sha256.c > > > > and then less than 50 lines of code to implement PBPDF2 (I didn't even > > bother putting in a library such as libext2fs): > > > > https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/misc/e4crypt.c#n405 > > > > This is all you would need to do if we don't put PBPDF2 in the kernel. > > Is it really that onerous? > > No. And in fact if you read upthread you will notice that I provided a link > to our implementation of both PBKDF1 & 2 and they're as small as you say. > They do everything we need. So I'm right there with you. > > But, PBKDF uses like 4K iterations (for WiFi passphrase -> key conversion > for example) to arrive at its solution. So you have implementations > hammering the kernel with system calls. > > So we can whinge at these implementations for 'being lazy', wring our hands, > say how everything was just a big mistake. Or maybe we can do something so > that the kernel isn't hammered needlessly... > 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. 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. Eric
