Re: [PATCH v2 3/3] NFSD: Sign filehandles

[Benjamin Coddington <bcodding@hammerspace.com>]

On 30 Jan 2026, at 7:58, Lionel Cons wrote:

> [You don't often get email from lionelcons1972@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Wed, 21 Jan 2026 at 22:03, Benjamin Coddington
> <bcodding@hammerspace.com> wrote:
>>
>> NFS clients may bypass restrictive directory permissions by using
>> open_by_handle() (or other available OS system call) to guess the
>> filehandles for files below that directory.
>>
>> In order to harden knfsd servers against this attack, create a method to
>> sign and verify filehandles using siphash as a MAC (Message Authentication
>> Code).  Filehandles that have been signed cannot be tampered with, nor can
>> clients reasonably guess correct filehandles and hashes that may exist in
>> parts of the filesystem they cannot access due to directory permissions.
>>
>> Append the 8 byte siphash to encoded filehandles for exports that have set
>> the "sign_fh" export option.  The filehandle's fh_auth_type is set to
>> FH_AT_MAC(1) to indicate the filehandle is signed.  Filehandles received from
>> clients are verified by comparing the appended hash to the expected hash.
>> If the MAC does not match the server responds with NFS error _BADHANDLE.
>> If unsigned filehandles are received for an export with "sign_fh" they are
>> rejected with NFS error _BADHANDLE.
>

Hi Lionel,

> Random questions:
> 1. CPU load: Linux NFSv4 servers consume LOTS of CPU time, which has
> become a HUGE problem for hosting them on embedded hardware (so no
> realistic NFSv4 server performance on an i.mx6 or RISC/V machine). And
> this has become much worse in the last two years. Did anyone measure
> the impact of this patch series?

We're essentially adding a siphash operation for every encode and decode of
a filehandle.  Siphash is lauded as "faster than sha255, slower than
xxhash".  Measuring the performance impact might look like crafting huge
compounds of GETATTR, but I honestly don't think (after network latency) the
performance impact will be measurable.

I attempted to measure a time difference between runs of fstests suite --
there were no significant measurable effects in my crude total time
calculations.

I could, if it pleases everyone, do a function profile for fh_append_mac and
fh_verify_mac - but the users of this option do not care about gating it
behind strict performance optimizations because we're fixing a security
problem that matters much more to those users.

> 2. Do NFS clients require any changes for this?

No - the filehandle is opaque.

Ben