4 ms·
This looks like an excellent idea. I will implement support for it in my libc immediately when it's available in a release kernel. Currently userspace has ince
by fefe23 4y ago
This looks like an excellent idea.
I will implement support for it in my libc immediately when it's available in a release kernel.
Currently userspace has incentive to roll their own RNG stuff.
This removes that, which is good for everyone. The less incentive you give people to write code that has already been written by other, more experienced people, the better.
I would go even further and export the kernel ciphers via vDSO.
Then user space could rely on those ciphers being optimized for the host CPU and side channel free instead of everybody bringing their own crypto primitives.
I don't think there is a good reason why gnupg and openssl would bring different crypto primitives.
- thadt 4y agoIsn't there already userspace access to the kernel's crypto machinery? https://www.kernel.org/doc/html/latest/crypto/userspace-if.html https://www.kernel.org/doc/html/latest/crypto/userspace-if.h...
- simcop2387 4y agoDoing it through vdso has performance advantages because it elides a lot of the syscall overhead. This works make the crypto stack be more advantageous they it was previously
- fefe23 4y agoYou are right, I was not aware of that! This way may actually have advantages over vDSO. Maybe you can set up IV and key with the kernel and then let the kernel do the crypto without having to have them in user space memory anymore. That would be a way to reduce risk in crypto applications, as long as you can prevent an attacker who has taken over the crypto app to retrieve the keys from the kernel. Maybe seccomp can help here. Very exciting!
- _8j50 4y agoWhat is your libc?
- mschuster91 4y agoJudging by the username, they may be German blogger Fefe, who has written their own libc: https://www.fefe.de/dietlibc/ https://www.fefe.de/dietlibc/