Re: [PATCH v2] NFSD: Rework encoding and decoding of nfsd4_deviceid

[Chuck Lever <chuck.lever@oracle.com>]

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