Re: fix_priv_head

[Bruce Fields <bfields@fieldses.org>]

On Thu, Jul 23, 2020 at 01:46:19PM -0400, Chuck Lever wrote:
> Hi Bruce-
> 
> I'm trying to figure out if fix_priv_head is still necessary. This
> was introduced by 7c9fdcfb1b64 ("[PATCH] knfsd: svcrpc: gss:
> server-side implementation of rpcsec_gss privacy").
> 
> static void
> fix_priv_head(struct xdr_buf *buf, int pad)
> {
>         if (buf->page_len == 0) {
>                 /* We need to adjust head and buf->len in tandem in this
>                  * case to make svc_defer() work--it finds the original
>                  * buffer start using buf->len - buf->head[0].iov_len. */
>                 buf->head[0].iov_len -= pad;
>         }
> }
> 
> It doesn't seem like unwrapping can ever result in a buffer length that
> is not quad-aligned. Is that simply a characteristic of modern enctypes?

This code is beofre any unwrapping.  We're looking at the length of the
encrypted (wrapped) object here, not the unwrapped buffer.

When using privacy, the body of an rpcsec_gss request is a single opaque
object consisting of the wrapped data.  So the question is whether
there's any case where the length of that object can be less than the
length remaining in the received buffer.

I think the only reason for bytes at the end is, yes, that that opaque
object is not a multiple of 4 and so rpc requires padding at the end.

I think that might be possible with encryption types that use cipher
text stealing, but I'm not certain.

--b.