6:13 p.m.
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