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

Hi,

On 27 February 2017 at 14:24, Johannes Berg [off-list ref] wrote:

On Fri, 2017-02-24 at 01:08 +0100, Andrew Zaborowski wrote:

quoted

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.

quoted

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.

It seems that would be NLA_NUL_STRING, whlie for NLA_STRING it's
optional, I know because I didn't add the NUL in my userspace and
things still worked.  We can copy the received nla_data into a buffer
and add the 0-byte there to support this as an option.  I don't have a
problem with the asymmetric usage though.

Anyway, patch applied.

Thanks
Best regards