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] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Oct 2023 08:47:55 +0200
From: Nicolas Dichtel <>
To: Jakub Kicinski <>
Cc: Johannes Berg <>,,,,,,, Thomas Haller <>
Subject: Re: [RFC] netlink: add variable-length / auto integers

Le 11/10/2023 à 17:52, Jakub Kicinski a écrit :
> On Wed, 11 Oct 2023 16:03:26 +0200 Nicolas Dichtel wrote:
>>> On Tue, 2023-10-10 at 17:33 -0700, Jakub Kicinski wrote:  
>>>> We currently push everyone to use padding to align 64b values in netlink.
>>>> I'm not sure what the story behind this is. I found this:
>> There was some attempts before:
>>>> but it doesn't go into details WRT the motivation.
>>>> Even for arches which don't have good unaligned access - I'd think
>>>> that access aligned to 4B *is* pretty efficient, and that's all
>>>> we need. Plus kernel deals with unaligned input. Why can't user space?  
>>> Hmm. I have a vague recollection that it was related to just not doing
>>> it - the kernel will do get_unaligned() or similar, but userspace if it
>>> just accesses it might take a trap on some architectures?
>>> But I can't find any record of this in public discussions, so ...  
>> If I remember well, at this time, we had some (old) architectures that triggered
>> traps (in kernel) when a 64-bit field was accessed and unaligned. Maybe a mix
>> between 64-bit kernel / 32-bit userspace, I don't remember exactly. The goal was
>> to align u64 fields on 8 bytes.
> Reading the discussions I think we can chalk the alignment up 
> to "old way of doing things". Discussion was about stats64, 
> if someone wants to access stats directly in the message then yes, 
> they care a lot about alignment.
> Today we try to steer people towards attr-per-field, rather than
> dumping structs. Instead of doing:
> 	struct stats *stats = nla_data(attr);
> 	print("A: %llu", stats->a);
> We will do:
> 	print("A: %llu", nla_get_u64(attrs[NLA_BLA_STAT_A]));
> Assuming nla_get_u64() is unalign-ready the problem doesn't exist.
> If user space goes thru a standard parsing library like YNL
> the application never even sees the raw netlink message,
> and deals with deserialized structs.
> Does the above sounds like a fair summary? If so I'll use it in 
> the commit message?
I think it is, it's ok for me.

Thank you,

Powered by blists - more mailing lists