Ok folks, I have working code:

Here is the ntirpc code:

https://github.com/nfs-ganesha/ntirpc/commits/gss

Here is a Ganesha pullup plus some reorg and debug in principle2uid:

https://github.com/ffilz/nfs-ganesha/commits/gss

I’d like a bit of review and maybe figure out how to do some more significant testing before I submit a pull request.

For testing I have copied a large (90k) file, reading it from the server and then writing the copy to the server using both krb5i and krb5p. I found a couple issues after it was working due to the debug code I have in.

I may have overdone the debug for day to day use, so I will probably remove some of it before finalizing the patches (like we probably don’t need to show the vectors at each step).

I did hit one issue that the cityhash checksum (that is used by dupreq) used to be over the whole request, but if a krb5i request is in multiple buffers we will only checksum the first buffer. This is comparable to what we do for checksum when not doing krb5i or krb5p. Since krb5p still requires the whole request to be in a single buffer, we still checksum the whole decrypted request.

Jeff Layton pointed out that the Linux client never sends RPC fragments which looks like that may be when we break a request into multiple buffers, so we may in practice never see any differences.

Given the reality of requests perhaps always being in a single buffer we should see the following benefits:

For gss_unwrap_iov, we save 1 data copy (extraction from the xdr_ioq) and decryption is in place (may not save memory access cycles but does save on memory allocation). If we DID see multiple buffers, we would still benefit from the decrypt in place.

For gss_mic_verify_iov, we save 1 data copy (extraction from the xdr_ioq) and verify is in place (may not save memory access cycles but does save on memory allocation). If we DID see multiple buffers, we would save most or all of the data copy (depending on if the MIC token is broken across buffers or not), and we still do the verify in place.

For gss_wrap_iov, we save 2 data copies (extraction of the data into a single buffer, copying the data back into the xdr stream) and encrypt in place (may not save memory access cycles but does save on memory allocation).

For gss_get_mic_iov, we save 2 data copies (extraction of the data into a single buffer, copying the data back into the xdr stream) and generate the MIC token in place (may not save memory access cycles but does save on memory allocation).

Frank