sockaddr used in the kernel? [LWN.net]

sockaddr used in the kernel?

Posted Nov 8, 2024 2:59 UTC (Fri) by clugstj (subscriber, #4020)
Parent article: The trouble with struct sockaddr's fake flexible array

"There are many places in the kernel where struct sockaddr is embedded within another structure"

How can this be anything but a bug? It's not big enough for many address formats.

to post comments

sockaddr used in the kernel?

Posted Nov 8, 2024 3:41 UTC (Fri) by iabervon (subscriber, #722) [Link] (12 responses)

I was wondering the same thing, so I looked at some of the patches. The answer is that it's an address from a specific family. E.g., your wireless card's MAC address is always a MAC address, not an IPv6 address. However, storing those 6 bytes next to the right 2 bytes and 8 unused bytes allows it to be passed in situ to functions that can take all sorts of addresses, without needing a ton of MAC-address-specific functions or using two function arguments per address in all of the functions.

sockaddr used in the kernel?

Posted Nov 8, 2024 7:02 UTC (Fri) by smurf (subscriber, #17840) [Link] (11 responses)

Well. But several addresses are longer anyway, so presumably the called functions restrict themselves to the sa_family-specified length.

So why do the short variants need padding up to an arbitrary 14, which happens to not match *any* actual address type's length?

sockaddr used in the kernel?

Posted Nov 8, 2024 7:58 UTC (Fri) by johill (subscriber, #25196) [Link] (10 responses)

Because ... history. The API to userspace was defined that way (some of it perhaps even back when 14 "was enough for everyone"), so it cannot be changed now.

Sure, wireless extensions wouldn't need 14 bytes for a MAC address there, only ever 6. But now it's stuck with 14 and can't use 6, and shouldn't use "14 or variable" either because it's embedded in other types.

sockaddr used in the kernel?

Posted Nov 8, 2024 21:31 UTC (Fri) by magfr (subscriber, #16052) [Link]

I am actually also curious about why the padding is needed?

Would it be confirming if the kernel returned a size of 8 and only filled in the sin_family, sin_port, and sin_addr fields?

I suppose the kernel does nothing with the padding as it is today so beeing explicit about it should be ok.

It should be noted that posix says sa_data must exist but it says nothing about it's size.

Then there is the issue that all the sockaddr_xx types must have the same alignment.

What I am going for is if the following is standards conforming:

typedef alignas(16) int16_t sa_family_t;
struct sockaddr { sa_family_t sa_family; char sa_data[]; };
struct sockaddr_in { sa_family_t sin_family; uint16_t sin_port; struct inaddr sin_addr; };

with an obvious caveat for what the alignment of sa_family_t should be.

In particular this makes sizeof(struct sockaddr) == 2 and sizeof(struct sockaddr_in) == 8 but note that
sizeof(struct sockaddr[2]) == 32 due to the alignment.

sockaddr used in the kernel?

Posted Nov 9, 2024 8:33 UTC (Sat) by smurf (subscriber, #17840) [Link] (8 responses)

Exactly which userspace API requires a 16-byte sockaddr? Using that type always requires a socket type. Some addresses are larger than the traditional sockaddr_t (Unix, IPv6, …) some are smaller (IPv4); there's nothing that requires zeroing out the padding in the latter.

So why does the kernel really need padded addresses anywhere? Just use / copy however many bytes the address's type requires and be done with it.

sockaddr used in the kernel?

Posted Nov 9, 2024 23:15 UTC (Sat) by johill (subscriber, #25196) [Link] (7 responses)

None requires 16 bytes, probably?

But for some APIs the address is _embedded_ into other structures (which is what most of the article is about), and changing the size now would change the position of everything that comes after it, breaking the ABI.

sockaddr used in the kernel?

Posted Nov 10, 2024 9:17 UTC (Sun) by smurf (subscriber, #17840) [Link] (6 responses)

Exactly which API are we talking about here? (Presumably one that doesn't support IPv6 …)

I'm not aware of any system call that embeds a sockaddr in some other data structure, but maybe that's just me.

sockaddr used in the kernel?

Posted Nov 10, 2024 19:20 UTC (Sun) by johill (subscriber, #25196) [Link] (5 responses)

Yeah, it's just you? ;-)

You can take a look at https://lore.kernel.org/netdev/cover.1729802213.git.gusta... for probably most/all of the APIs affected.

sockaddr used in the kernel?

Posted Nov 10, 2024 21:18 UTC (Sun) by smurf (subscriber, #17840) [Link] (4 responses)

Ah, so ioctls for the IPv4 ARP table, legacy routing, and similar stuff that frankly I'd deprecate in a heartbeat. Does anybody (except /sbin/arp AFAICT) still not use netlink for that, these days?

Oh well.

sockaddr used in the kernel?

Posted Nov 10, 2024 21:32 UTC (Sun) by johill (subscriber, #25196) [Link] (3 responses)

A surprisingly large number of tools still use(d) wext, but I'm kicking them out - WiFi7 hardware no longer supports wext in any way. Let's see if I can win that fight ...

sockaddr used in the kernel?

Posted Nov 11, 2024 9:21 UTC (Mon) by Sesse (subscriber, #53779) [Link] (2 responses)

I'd happily switch to iw, except… I really like the output of iwconfig and iwlist? I don't understand why we need to couple API changes with how a CLI works (especially when said CLI moves more towards the needs of low-level expert users).

sockaddr used in the kernel?

Posted Nov 11, 2024 10:36 UTC (Mon) by mb (subscriber, #50428) [Link] (1 responses)

cfg80211 has always included a wireless-extensions API emulation to keep iwconfig and lwlist working.
So it's exactly the opposite of what you say: The fundamental API has changed, but the obsolete CLI and its obsolete API have not.
So, if almost two decades is not enough for you to adapt to the "new" iw CLI, then you can keep using iwconfig/iwlist.

sockaddr used in the kernel?

Posted Nov 11, 2024 12:34 UTC (Mon) by johill (subscriber, #25196) [Link]

Well, no, as I said - I'm removing that part too now for WiFi7 hardware. There are some technical reasons for that even.

As for the question about why it "must" be coupled with changes in the CLI, well ... it doesn't really need to be, but when writing a completely new tool that for the most part has completely new semantics, keeping the CLI intact really isn't the first priority.

If you want to submit patches to make 'iw' have a mode where it behaves like iwconfig/iwlist for a subset of functionality, I guess I'd even apply them if they're reasonably well implemented.

But you can keep using it for eternity, for all I care, just don't expect new hardware support etc., and then you can just keep using an old kernel version too.