Re: Importing libraries for the kernel
On Tue, Dec 18, 2018 at 08:53:54AM -0500, Thor Lancelot Simon wrote: > They did _not_ cause measureable performance problems of any kind, and > though it is theoretically possible to do this sort of thing via a > tightly-protected userspace helper process, I prototyped that too and > it gets very ugly, very fast -- the in-kernel way with a thread is, I > believe, better. Also note that it is pretty straight-forward to give such a thread the "right" to use the FPU (or similar PCUs) in the kernel. Martin
Re: Importing libraries for the kernel
On Fri, Dec 14, 2018 at 03:19:45PM +0100, Joerg Sonnenberger wrote: > On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote: > > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote: > > > > > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > > > > Before that, I want to ask about how to import cryptography > > > > libraries needed tor the implementation. The libraries are > > > > libb2[1] and libsodium[2]: the former is for blake2s and > > > > the latter is for curve25519 and [x]chacha20-poly1305. > > > > > > I don't really have a problem with Blake2s, but I have serious concerns > > > for doing asymmetric cryptography in the kernel. In fact, it is one of > > > the IMHO very questionable design decisions behind WireGuard and > > > something I don't want to see repeated in NetBSD. > > > > Can you clarify the concerns? > > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC We have an existing facility for doing slow cryptographic operations asynchronously in the kernel. Except where architectures have really fast, instruction-style hardware support for asymmetric crypto operations (and perhaps even there depending on operand size) this stuff should be done in a thread interfacing to the rest of the kernel through the existing opencrypto framework. That said, I believe we should have asymmetric crypto operations in the kernel for executable and security policy signing. In fact, I believe it strongly enough to have implemented it (interfaced via opencrypto as described above) twice -- but I don't own either implementation and thus can't contribute them. They did _not_ cause measureable performance problems of any kind, and though it is theoretically possible to do this sort of thing via a tightly-protected userspace helper process, I prototyped that too and it gets very ugly, very fast -- the in-kernel way with a thread is, I believe, better. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov
Re: Importing libraries for the kernel
>>> Asymmetrical cryptography is slow and complex. >> Didn't that ship sail long ago? I recall seeing people talking >> about putting entire languages into the kernel, in some cases even >> including jitters. Much as I dislike this, I find that far more "no >> way in hell is that going into _my_ machines' kernels!". > Few of this things require 10k+ cycle operations in one go. Neither does asymmetric crypto - at least not the crypto I know. It takes a (comparative) lot of CPU, yes, but it doesn't have to be all in one go; there is nothing that makes it impossible to do the work in multiple smaller pieces. >> I also disagree that asymmetric crypto is necessarily all that >> complex. [...] > Correct and fast implementations of large number arithmetic are > complex, esp. if you also want to avoid the typical set of timing > leaks. What is the threat model? This is in the kernel, remember; whom is there to potentially leak anything to? (That's a serious question; it is not clear to me why anyone thinks asymmetric crypto would be a good idea in the kernel - perhaps I missed some list mail? - so I don't know what it's trying to defend against. I can easily imagine some uses, but for the ones I've come up with so far, timing leaks are completely irrelevant.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Importing libraries for the kernel
> On Dec 14, 2018, at 2:16 PM, Joerg Sonnenberger wrote: > > On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote: > ... >> I also disagree that asymmetric crypto is necessarily all that complex. >> Some asymmetric crypto algorithms require nothing more complex than >> large-number arithmetic. (Slow, yes, but not particularly complex.) > > Correct and fast implementations of large number arithmetic are > complex, esp. if you also want to avoid the typical set of timing leaks. > This applies to operation sets used by RSA as well as those used by ECC. > Different classes of operations, but a mine field to get right. Indeed, side channel attacks of all kinds. There are lots of ways to get into trouble. Consider the acoustic attack on RSA that allowed researchers to recover private keys by listening to the sound made by cellphones running the RSA algorithm. https://www.cs.tau.ac.il/~tromer/papers/acoustic-20131218.pdf paul
Re: Importing libraries for the kernel
On Fri, Dec 14, 2018 at 01:00:25PM -0500, Mouse wrote: > >>> [...] I have serious concerns for doing asymmetric cryptography in > >>> the kernel [...] > >> Can you clarify the concerns? > > Asymmetrical cryptography is slow and complex. [...] The > > implementation is non-trivial [...] > > Didn't that ship sail long ago? I recall seeing people talking about > putting entire languages into the kernel, in some cases even including > jitters. Much as I dislike this, I find that far more "no way in hell > is that going into _my_ machines' kernels!". Few of this things require 10k+ cycle operations in one go. > I also disagree that asymmetric crypto is necessarily all that complex. > Some asymmetric crypto algorithms require nothing more complex than > large-number arithmetic. (Slow, yes, but not particularly complex.) Correct and fast implementations of large number arithmetic are complex, esp. if you also want to avoid the typical set of timing leaks. This applies to operation sets used by RSA as well as those used by ECC. Different classes of operations, but a mine field to get right. Joerg
Re: Importing libraries for the kernel
>>> [...] I have serious concerns for doing asymmetric cryptography in >>> the kernel [...] >> Can you clarify the concerns? > Asymmetrical cryptography is slow and complex. [...] The > implementation is non-trivial [...] Didn't that ship sail long ago? I recall seeing people talking about putting entire languages into the kernel, in some cases even including jitters. Much as I dislike this, I find that far more "no way in hell is that going into _my_ machines' kernels!". I also disagree that asymmetric crypto is necessarily all that complex. Some asymmetric crypto algorithms require nothing more complex than large-number arithmetic. (Slow, yes, but not particularly complex.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Importing libraries for the kernel
> On Dec 14, 2018, at 6:19 AM, Joerg Sonnenberger wrote: > Asymmetrical cryptography is slow and complex. On many architectures, > the kernel will only be able to use slower non-SIMD implementations. ECC > still easily requires 10k cycles per operation. The implementation is > non-trivial in terms of code size and historically riddled with tiny > tricky issues ranging from corner cases in the math to timing. I haven't > yet heard a really good argument why the key exchange must be part of > the kernel beyond the inability of the Linux community to coordinate > different projects. Agreed, it's best if that stuff is done in user space. -- thorpej
Re: Importing libraries for the kernel
On Thu, Dec 13, 2018 at 11:07:23PM +0900, Ryota Ozaki wrote: > On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote: > > > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > > > Before that, I want to ask about how to import cryptography > > > libraries needed tor the implementation. The libraries are > > > libb2[1] and libsodium[2]: the former is for blake2s and > > > the latter is for curve25519 and [x]chacha20-poly1305. > > > > I don't really have a problem with Blake2s, but I have serious concerns > > for doing asymmetric cryptography in the kernel. In fact, it is one of > > the IMHO very questionable design decisions behind WireGuard and > > something I don't want to see repeated in NetBSD. > > Can you clarify the concerns? Asymmetrical cryptography is slow and complex. On many architectures, the kernel will only be able to use slower non-SIMD implementations. ECC still easily requires 10k cycles per operation. The implementation is non-trivial in terms of code size and historically riddled with tiny tricky issues ranging from corner cases in the math to timing. I haven't yet heard a really good argument why the key exchange must be part of the kernel beyond the inability of the Linux community to coordinate different projects. Joerg
Re: Importing libraries for the kernel
On Thu, Dec 13, 2018 at 6:30 AM Joerg Sonnenberger wrote: > > On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > > Before that, I want to ask about how to import cryptography > > libraries needed tor the implementation. The libraries are > > libb2[1] and libsodium[2]: the former is for blake2s and > > the latter is for curve25519 and [x]chacha20-poly1305. > > I don't really have a problem with Blake2s, but I have serious concerns > for doing asymmetric cryptography in the kernel. In fact, it is one of > the IMHO very questionable design decisions behind WireGuard and > something I don't want to see repeated in NetBSD. Can you clarify the concerns? ozaki-r
Re: Importing libraries for the kernel
On Thu, Dec 13, 2018 at 12:58:21AM +0900, Ryota Ozaki wrote: > Before that, I want to ask about how to import cryptography > libraries needed tor the implementation. The libraries are > libb2[1] and libsodium[2]: the former is for blake2s and > the latter is for curve25519 and [x]chacha20-poly1305. I don't really have a problem with Blake2s, but I have serious concerns for doing asymmetric cryptography in the kernel. In fact, it is one of the IMHO very questionable design decisions behind WireGuard and something I don't want to see repeated in NetBSD. Joerg
Re: Importing libraries for the kernel
On Thu, Dec 13, 2018 at 2:12 AM Greg Troxel wrote: > > m...@netbsd.org writes: > > > I don't expect there to be any problems with the ISC license. It's the > > preferred license for OpenBSD and we use a lot of their code (it's > > everywhere in sys/dev/) > > Agreed that the license is ok. > > > external, as I understand it, means "please upstream your changes, and > > avoid unnecessary local changes". > > Agreed. > > And also that we have a plan/expectation of tracking changes and > improvements that upstream makes. Code that is not in external more or > less implies that we are the maintainer. For these libraries, my > expectation is that they are being actively maintained and that we will > want to update to newer upstream versions from time to time. I think libsodium matches the case. The project is active and we should track the updates. OTOH for libb2 (blake2s), we need just two files (.h and .c) and those seems to be a reference implementation of the algorithm and unlikely to update, at least, frequently. So just copying the files may work. Note that it's not to say that I don't want to do the formal process (because I've already done the task in my local changes). I just don't want to increase unnecessary files in the repository if possible (and if preferable). Anyway thank you for suggestions! ozaki-r
Re: Importing libraries for the kernel
m...@netbsd.org writes: > I don't expect there to be any problems with the ISC license. It's the > preferred license for OpenBSD and we use a lot of their code (it's > everywhere in sys/dev/) Agreed that the license is ok. > external, as I understand it, means "please upstream your changes, and > avoid unnecessary local changes". Agreed. And also that we have a plan/expectation of tracking changes and improvements that upstream makes. Code that is not in external more or less implies that we are the maintainer. For these libraries, my expectation is that they are being actively maintained and that we will want to update to newer upstream versions from time to time.
Re: Importing libraries for the kernel
I don't expect there to be any problems with the ISC license. It's the preferred license for OpenBSD and we use a lot of their code (it's everywhere in sys/dev/) external, as I understand it, means "please upstream your changes, and avoid unnecessary local changes".
