net80211: create IEEE80211_KEYBUF_128_SIZE / IEEE80211_MICBUF_128_SIZE

[adrian]

Summary

The IEEE80211_KEYBUF_SIZE and IEEE80211_MICBUF_SIZE are sprinkled
throughout the net80211 stack, ioctl API and drivers. This makes it
challenging to (eventually) up IEEE80211_KEYBUF_SIZE to support 256 /
384 bit encryption as, well, it'll break every single driver and the
ioctl API in doing so.

So as part of this, let's start to separate out the current key/mic
buffer size from what drivers and the ioctl layer are using.
Drivers especially shouldn't be using these definitions as their
key sizes are hardware / firmware API limits, not net80211 limits.
Ideally drivers would define their own key buffer / mic buffer
sizes and only copy in keys up to that length (and fail keys
that are too large) but the current net80211 API isn't there yet.

This doesn't yet change what defines / buffer sizes are used in the
ioctl layer. I'm going to plan out some subsequent work to
separate out those defines and ioctl APIs so they maintain using
the 128 bit key/mic buffer sizes and will copy them in/out of any
larger net80211 key buffer size in the future.

[bz]

sys/net80211/ieee80211_crypto.h

42

I think you need to make this comment more precise as in theory no fixed defined length you ever be used in a future ioctl API anymore unless we want to repeat the mistakes of the past.

It might make way more sense to add the description the "left" definitions below?

48

Well, that comment really wants to either be done or have a better explanation or become an XXX TODO finish transition to ...?

49

Also careful, they are used in ifconfig!

58

Given you do the ones in crypto_wep, why not this one?

99

Those two defines should also be fairly sized forever like this (not the array above!)

[adrian]

sys/net80211/ieee80211_crypto.h

42

I didn't change the name of the ioctl key size defines in this diff because doing so would require that I also double/triple check the userland code to make sure it's also using the right defines.

I'll work on a subsequent commit that defines the current ioctl API using something new like IEEE80211_IOCTL_KEYBUF_SIZE, and then a subsequent diff to rename this from IEEE80211_KEYBUF_SIZE to something else that's net80211 internals specific, so any code that still uses IEEE80211_KEYBUF_SIZE will just fail to compile.

That seems much less error prone to me.

49

yup, see above comment. All of the userland stuff will need to be updated before I can delete IEEE80211_KEYBUF_SIZE / IEEE80211_MICBUF_SIZE use.

58

oh this is a good question, I /think/ this is not the ioctl API, so it's just representing the key storage size. And nothing else is using it; it likely can be deleted in a follow-up commit.

99

What do you mean by "fairly sized forever" ?

My hope is to eventually introduce something like NET80211_KEY_BUF_SIZE / NET80211_MIC_BUF_SIZE, define them very specifically as internal to net80211/drivers and not for public userland API consumption, and then since we've hidden the direct field access away, drivers don't actually have to know about those sizes to get to the key / mic contents.

[adrian]

sys/net80211/ieee80211_crypto.h

58

Deleted in a subsequent commit - D57312 .