Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

In D44920#1026551, @emaste wrote:

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

in /theory/ the key struct is flexible, as it has the payload at the end and a len at the beginning.

in /practice/ I saw some weird stuff happen here, so I need to go and revisit it all before i land. I /think/ passing in a larger key request (even with wk_len being set properly) to an older net80211 caused EINVAL to be returned and that could be problematic. However, that's solvable in userland with a bit of fore-thought..

OK, I rebuilt world and found where this breaks userland.

ieee80211_ioctl_setkey() has an explicit length check to ensure the submitted struct matches its own struct.

We could support longer keys by simply removing that check and ensure that the request length and key length fit inside the buffer length provided.
I'm however worried that this length check is hiding some much earlier change in structure size (rather than changing the ioctl value, adding versioning, etc.)

So before I land this particular change, we're going to want to have a discussion about how to make this forward and backward compatible.

wpa_supplicant < net80211 is easy - just handle the size check differently.
wpa_supplicant > net80211 is less easy - it'll need to know about the "old" (128 bit key size) and "new" (larger? 384 bit key size? variable key size?) and retry setting the 128 bit keys using the older API if the newer one fails.

The nice thing here is we can extend the key request struct to include more fields with the change, eg adding support for MFP keys (key slots 5 and 6), key id 0 and 1 for unicast session key switchover, etc, etc.

Maybe we can get away with using i_val == 1 for "version 1" of the ioctl call (as all the previous ones will definitely use i_val == 0) and just trust older kernels to fail if the size check is different?

In D44920#1026551, @emaste wrote:

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

good question, it's a similar problem to what wpa/hostapd driver_bsd.c has.

I'm still thinking about it, and letting the landed code bake in -HEAD. Stay tuned.

The real problem isn't the ABI key size, it's that the current net80211 API routine expects the ioctl size is fixed. If that size check wasn't there and we relied on the key request key size and verified it fit inside the ioctl buffer size then we'd be fine.

The fact that the key size is used in both internal net80211 structures /and/ the keyreq ioctl is also part of the problem.