Re: [PATCH 1/2] mac80211_hwsim: Make sure NEW_RADIO contains final name

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:
> On 23 February 2017 at 13:02, Andrew Zaborowski
> <andrew.zaborowski@intel.com> wrote:
> > ieee80211_alloc_hw_nm will validate the requested name (if any)
> > before
> > creating the new device and may use a name different from the one
> > requested rather than fail.  Make sure the HWSIM_CMD_NEW_RADIO
> > event/response generated has the final name or userspace will
> > receive
> > the wrong name.  Note that mac80211_hwsim_new_radio may now modify
> > params.
> 
> Also related to this I find that the HWSIM_ATTR_RADIO_NAME attributes
> emitted contain the name string and are exactly of the right length
> while the HWSIM_ATTR_RADIO_NAME attributes received by the kernel are
> assumed to be NUL-terminated.  

I'll agree this is a bit strange - I guess it's too late to fix now
though since userspace might assume "length/data" is the string, rather
than "0-terminated" (especially if there's something like python
userspace where strings can trivially contain NUL bytes).

nla_put_string() would have added the NUL byte.

> Is there a guarantee that a 0-byte
> follows an attribute, or should this be changed for consistency?

        [HWSIM_ATTR_RADIO_NAME] = { .type = NLA_STRING },

enforces that a NUL byte *must* be present when userspace gives us the
information, so we're save - just asymmetric.

Anyway, patch applied.

johannes