Date: Mon, 13 Jan 2020 20:53:23 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, Benjamin Kaduk <kaduk@mit.edu> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: how to use the ktls Message-ID: <YQBPR0101MB1427865095BC1C3B7352DF8FDD350@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <c1039245-5574-3279-956d-26cf378c71e5@FreeBSD.org> References: <YQBPR0101MB142760894682CA3663CB53BDDD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> <YQBPR0101MB14276B495EF90AD4CCE04F9ADD390@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <20200113042310.GF27483@kduck.mit.edu>, <c1039245-5574-3279-956d-26cf378c71e5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:=0A= >On 1/12/20 8:23 PM, Benjamin Kaduk wrote:=0A= >> On Thu, Jan 09, 2020 at 10:53:38PM +0000, Rick Macklem wrote:=0A= >>> John Baldwin wrote:=0A= >>>> On 1/7/20 3:02 PM, Rick Macklem wrote:=0A= >>>>> Hi,=0A= >>>>>=0A= >>>>> Now that I've completed NFSv4.2 I'm on to the next project, which is = making NFS=0A= >>>>> work over TLS.=0A= >>>>> Of course, I know absolutely nothing about TLS, which will make this = an interesting=0A= >>>>> exercise for me.=0A= >>>>> I did find simple server code in the OpenSSL doc. which at least give= s me a starting=0A= >>>>> point for the initialization stuff.=0A= >>>>> As I understand it, this initialization must be done in userspace?=0A= >>>>>=0A= >>>>> Then somehow, the ktls takes over and does the encryption of the=0A= >>>>> data being sent on the socket via sosend_generic(). Does that sound r= ight?=0A= >>>>>=0A= >>>>> So, how does the kernel know the stuff that the initialization phase = (handshake)=0A= >>>>> figures out, or is it magic I don't have to worry about?=0A= >>>>>=0A= >>>>> Don't waste much time replying to this. A few quick hints will keep m= e going for=0A= >>>>> now. (From what I've seen sofar, this TLS stuff isn't simple. And I t= hought Kerberos=0A= >>>>> was a pain.;-)=0A= >>>>>=0A= >>>>> Thanks in advance for any hints, rick=0A= >>>>=0A= >>>> Hmmm, this might be a fair bit of work indeed.=0A= >>> If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if i= t doesn't make that, oh well..=0A= >>>=0A= >>>> Right now KTLS only works for transmit (though I have some WIP for rec= eive).=0A= >>> Hopefully your WIP will make progress someday, or I might be able to wo= rk on it.=0A= >>>=0A= >>>> KTLS does assumes that the initial handshake and key negotiation is ha= ndled by=0A= >>>> OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel whi= ch=0A= >>>> session keys to use.=0A= >>> Yea, I figured I'd need a daemon like the gssd for this. The krpc makes= it a little=0A= >>> more fun, since it handles TCP connections in the kernel.=0A= >>>=0A= >>>> I think what you would want to do is use something like OpenSSL_connec= t() in=0A= >>>> userspace, and then check to see if KTLS "worked".=0A= >>> Thanks (and for the code below). I found the simple server code in the = OpenSSL doc,=0A= >>> but the client code gets a web page and is quite involved.=0A= >>>=0A= >>>> If it did, you can tell=0A= >>>> the kernel it can write to the socket directly, otherwise you will hav= e to=0A= >>>> bounce data back out to userspace to run it through SSL_write() and ha= ve=0A= >>>> userspace do SSL_read() and then feed data into the kernel.=0A= >>> I don't think bouncing the data up/down to/from userland would work wel= l.=0A= >>> I'd say "if it can't be done in the kernel, too bad". The above could b= e used for=0A= >>> a NULL RPC to see it is working, for the client.=0A= >>=0A= >> So you're saying that we'd only support rpc-over-tls as an NFS client an= d=0A= >> not as a server, at least until the WIP for ktls read appears?=0A= Actually, I'd say that neither NFS client nor server will work over tls unt= il=0A= the receive side works, since NFS RPCs result in bi-directional traffic.=0A= =0A= >To be clear, I have KTLS RX working with TOE right now. I have a design i= n my=0A= >head for KTLS RX that would use software and co-processor engines via OCF = such=0A= >as aesni(4) and ccr(4) that I hope to implement in the next few months, so= KTLS=0A= >RX isn't too far off. OpenSSL already supports KTLS RX on Linux and the F= reeBSD=0A= >patches I already have use the same API. (Each received TLS frame is read= via=0A= >recvmsg() with the TLS header fields in a cmsg.)=0A= Sounds good. It will be a while before I get to the stage where I need it.= =0A= I'm currently working on how to give userland access to a socket created i= n the=0A= kernel, so that a daemon can use it.=0A= =0A= Have fun with it, rick=0A= =0A= --=0A= John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB1427865095BC1C3B7352DF8FDD350>