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

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>

-- 
Chuck Lever