linux-kernel - Re: [PATCH v2] NFSD: Rework encoding and decoding of nfsd4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <81f534a7-8763-492d-bbcc-bc49b22d07e8@oracle.com>
Date: Wed, 23 Jul 2025 10:35:29 -0400
From: Chuck Lever <chuck.lever@...cle.com>
To: NeilBrown <neil@...wn.name>
Cc: Christoph Hellwig <hch@...radead.org>,
        Sergey Bashirov <sergeybashirov@...il.com>,
        Jeff Layton
 <jlayton@...nel.org>,
        Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>,
        Tom Talpey <tom@...pey.com>, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] NFSD: Rework encoding and decoding of nfsd4_deviceid

On 7/22/25 9:28 PM, NeilBrown wrote:
> On Wed, 23 Jul 2025, Chuck Lever wrote:
>> On 7/22/25 1:36 AM, Christoph Hellwig wrote:
>>> On Mon, Jul 21, 2025 at 05:48:55PM +0300, Sergey Bashirov wrote:
>>>> Compilers may optimize the layout of C structures,
>>>
>>> By interpreting the standard in the most hostile way: yes.
>>> In practice: no.
>>
>> Earnest question: Is NFSD/XDR properly insulated against the "randomize
>> structure layout" option?
>>
>>
>>> Just about every file system on-disk format and every network wire
>>> protocol depends on the compiler not "optimizing" properly padded
>>> C structures.
>> It's an intrinsic assumption that is not documented in the code or
>> anywhere else. IMO that is a latent banana peel.
> 
> We could document it in the code with __no_randomize_layout after the
> structure definition.

We might also want __attribute__((packed)) or even
__attribute__((packed, aligned(4))).

That still leaves undocumented the fact that the fields in the structure
are treated as both endian types. In most other XDR functions we have
been careful to write source code that shows where endianness changes
or, conversely, where endianness is not consequential.


> But currently the only structures that are randomized in Linux are those
> which are entirely function pointers, and those marked
> __randomize_layout.
> 
> (See documentation for "RANDSTRUCT_FULL")
> 
>>
>> While not urgent, this is a defensive change and it improves code
>> portability amongst compilers and languages (eg, Rust).
>>
> 
> I'm neither for nor against the change.  I would be interested to know
> how much it changes the code side (if at all).
> 
> NeilBrown
> 


-- 
Chuck Lever