On Fri, Oct 16, 2020 at 05:18:26PM +0100, David Howells wrote: > Hi Herbert, Dave, Trond, > > I've written basic gssapi-derived security support for AF_RXRPC: > > > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk > > I've borrowed some bits from net/sunrpc/auth_gss/ but there's a lot in there > that is quite specific to the sunrpc module that makes it hard to use for > rxrpc (dprintk, struct xdr_buf). > > Further, I've implemented some more enctypes that aren't supported yet by > gssapi (AES with sha256/sha384 and Camellia), and that requires some changes > to the handling as AES with sha384 has a 24-byte checksum size and a 24-byte > calculated key size for Kc and Ki but a 32-byte Ke. > > Should I pull the core out and try to make it common? If so, should I move it > to crypto/ or lib/, or perhaps put it in net/gssapi/? > > There are two components to it: > > (1) Key derivation steps. > > My thought is to use xdr_netobj or something similar for to communicate > between the steps (though I'd prefer to change .data to be a void* rather > than u8*). > > (2) Encryption/checksumming. > > My thought is to make this interface use scattergather lists[*] since > that's what the crypto encryption API requires (though not the hash API). > > If I do this, should I create a "kerberos" crypto API for the data wrapping > functions? I'm not sure that it quite matches the existing APIs because the > size of the input data will likely not match the size of the output data and > it's "one shot" as it needs to deal with a checksum. > > Or I can just keep my implementation separate inside net/rxrpc/.
I'd love to share whatever we can, though I'm not really sure what's involved. Certainly some careful testing at least. It's been about 15 years since I really worked on that code. I remember struggling with struct xdr_buf. The client and server support zero-copy, so requests and replies are represented by a combination of a couple of linear buffers plus an array of pages. My memory is that the (undocumented) meanings of the fields of the xdr_buf were different for request and replies and for server and client, and getting them right took some trial and error. --b.
