From: Chuck Lever <chuck.lever@oracle.com>
To: Rick Macklem <rick.macklem@gmail.com>
Cc: Neil Brown <neilb@suse.de>, Jeff Layton <jlayton@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH v2 0/2] Fix XDR encoding near page boundaries
Date: Tue, 24 Dec 2024 09:16:47 -0500 [thread overview]
Message-ID: <7daa45c2-13c4-4617-9f9e-7be5ae607b4a@oracle.com> (raw)
In-Reply-To: <CAM5tNy74=vqdSaciOKus0SeU4eBB+Vb-TzKO060t1RSdAQYGxQ@mail.gmail.com>
On 12/23/24 6:22 PM, Rick Macklem wrote:
> On Mon, Dec 23, 2024 at 10:07 AM <cel@kernel.org> wrote:
>>
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> Build out the patch series to address the longstanding bug pointed
>> out by J David and Rick Macklem.
>>
>> At least during NFSv4 COMPOUND encoding, using
>> write_bytes_to_xdr_buf() seems less brittle than saving a pointer
>> into the XDR encoding buffer.
>>
>> I have one more patch to add (not yet included) that addresses the
>> issue in the NFSv4 READ and READ_PLUS encoders.
> It also looks like there is a similar situation in nfsd4_encode_fattr4().
> It uses attrlen_p (only a 4byte xdr_reserve_space(), so safe for now.
>
> You might just regret choosing to not wire down the "safe to use
> xdr_reserve_space() for 4 bytes" semantic, but it is obviously up to you.
I'm 100% behind the idea of making it hard or impossible to code
things the wrong way.
But I'm not sure what you mean by "wire down". I can't think of a way
to enforce the "only 4 octets or less" rule -- just having a helper
function with that name documents it but doesn't enforce it.
My plan is to replace the obviously unsafe call sites immediately,
document the desired long-term semantics, then replace the other
"safe for now" call sites over time.
I've found a few other potentially unsafe server-side callers:
* gss_wrap_req_integ
* gss_wrap_req_priv
* unx_marshal
I consider these "safe for now" because the reserved space is guaranteed
to be in the XDR buffer's head iovec, far away from page boundaries.
I'm hoping that no-one introduces new unsafe call sites in the meantime.
We should be able to catch that in review.
That also buys some time to come up with something better.
> rick
>
>>
>> Changes since RFC:
>> - Document the guarantees around pointer returned by xdr_reserve_space()
>> - Use write_bytes_to_xdr_buf() instead
>>
>> Chuck Lever (2):
>> NFSD: Encode COMPOUND operation status on page boundaries
>> SUNRPC: Document validity guarantees of the pointer returned by
>> reserve_space
>>
>> fs/nfsd/nfs4xdr.c | 20 ++++++++++----------
>> net/sunrpc/xdr.c | 3 +++
>> 2 files changed, 13 insertions(+), 10 deletions(-)
>>
>> --
>> 2.47.0
>>
--
Chuck Lever
next prev parent reply other threads:[~2024-12-24 14:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-23 18:07 [PATCH v2 0/2] Fix XDR encoding near page boundaries cel
2024-12-23 18:07 ` [PATCH v2 1/2] NFSD: Encode COMPOUND operation status on " cel
2024-12-23 23:46 ` Rick Macklem
2024-12-24 23:19 ` NeilBrown
2024-12-25 15:53 ` Chuck Lever
2024-12-23 18:07 ` [PATCH v2 2/2] SUNRPC: Document validity guarantees of the pointer returned by reserve_space cel
2024-12-23 23:22 ` [PATCH v2 0/2] Fix XDR encoding near page boundaries Rick Macklem
2024-12-24 14:16 ` Chuck Lever [this message]
2024-12-24 15:50 ` Rick Macklem
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7daa45c2-13c4-4617-9f9e-7be5ae607b4a@oracle.com \
--to=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=rick.macklem@gmail.com \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox