On Tue, Mar 03, 2026 at 02:41:33PM -0500, Chuck Lever wrote:

On Tue, Mar 3, 2026, at 1:00 PM, Matthew Wilcox wrote:

quoted

On Tue, Mar 03, 2026 at 11:29:32AM -0500, Chuck Lever wrote:

quoted

Profiling NFSD under an iozone workload showed that hardened
usercopy checks consume roughly 1.3% of CPU in the TCP receive
path. The runtime check in check_object_size() validates that
copy buffers reside in expected slab regions, which is
meaningful when data crosses the user/kernel boundary but adds
no value when both source and destination are kernel addresses.

I'm not sure I'd go as far as "no value".  I could see an attack which
managed to trick the kernel into copying past the end of a slab object
and sending the contents of that buffer across the network to an attacker.

Or I guess in this case you're talking about copying _to_ a slab object.
Then we could see a network attacker somewhow confusing the kernel into
copying past the end of the object they allocated, overwriting slab
metadata and/or the contents of the next object in the slab.

Limited value, sure.  And the performance change you're showing here
certainly isn't nothing!

To be clear, I'm absolutely interested in not degrading our security
posture. But NFSD (and other storage ULPs, for example) do a lot of
internal data copying that could be more efficient.

I would place the "trick the kernel into copying past the end of
a slab object" attack in the category of "you should sanitize your
input better"... Perhaps the existing copy_to_iter protection is
a general salve that could be replaced by something more narrow
and less costly. </hand wave>

As I understand it, and I'm sure Kees will correct me if I'm wrong,
the hardened usercopy stuff is always "you should have sanitised your
input before you got here"; it's never "yolo, just copy the amount the
user asked for and if it's too much, the hardening will catch it".

I'm definitely open to the original patch, as well as other alternatives
that narrow down the cases where we can prove that we're not doing
anything wrong.  I just want to be sure that we all understand what
tradeoffs we're making and why.