Hello Johannes and all,
This patch series suggests a couple of minor changes related to WPA3 OWE.
One patch adds define for OWE AKM suite. Another patch disables strict
validation for UPDATE_OWE command.
When strict validation is enabled, kernel rejects appropriate hostapd
command with 'unsupported attribute' error message. This message is
related to status attribute NL80211_ATTR_STATUS_CODE, which is added
to nl80211 messsage using nla_put_u16.
Let me know if disabling strict validation is now frowned upon and
there is a more appropriate way to make existing hostapd command to
work properly.
Regards,
Sergey
Sergey Matyukevich (2):
cfg80211: skip strict validation for UDPATE_OWE command
ieee80211: add WPA3 OWE AKM suite selector
include/linux/ieee80211.h | 1 +
net/wireless/nl80211.c | 1 +
2 files changed, 2 insertions(+)
--
2.11.0
Do not perform strict validation of UPDATE_OWE command.
Otherwise, kernel rejects command executed by hostapd.
Signed-off-by: Sergey Matyukevich <[email protected]>
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 33fe6ac1c242..92e0723c21fa 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -14837,6 +14837,7 @@ static const struct genl_ops nl80211_ops[] = {
},
{
.cmd = NL80211_CMD_UPDATE_OWE_INFO,
+ .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
.doit = nl80211_update_owe_info,
.flags = GENL_ADMIN_PERM,
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
--
2.11.0
Add the definition for Opportunistic Wireless Encryption AKM selector.
Signed-off-by: Sergey Matyukevich <[email protected]>
---
include/linux/ieee80211.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6f3e7c5c600a..33d907eec0b6 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -3044,6 +3044,7 @@ struct ieee80211_multiple_bssid_configuration {
#define WLAN_AKM_SUITE_FILS_SHA384 SUITE(0x000FAC, 15)
#define WLAN_AKM_SUITE_FT_FILS_SHA256 SUITE(0x000FAC, 16)
#define WLAN_AKM_SUITE_FT_FILS_SHA384 SUITE(0x000FAC, 17)
+#define WLAN_AKM_SUITE_OWE SUITE(0x000FAC, 18)
#define WLAN_MAX_KEY_LEN 32
--
2.11.0
On Thu, 2020-02-13 at 09:07 +0000, Sergey Matyukevich wrote:
> Do not perform strict validation of UPDATE_OWE command.
> Otherwise, kernel rejects command executed by hostapd.
Can't we fix hostapd? I mean, it's a relatively new command, so why
shouldn't we validate it strictly?
johannes
On Thu, Feb 13, 2020 at 10:12:47AM +0100, Johannes Berg wrote:
>
> [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.
>
> On Thu, 2020-02-13 at 09:07 +0000, Sergey Matyukevich wrote:
> > Do not perform strict validation of UPDATE_OWE command.
> > Otherwise, kernel rejects command executed by hostapd.
>
> Can't we fix hostapd? I mean, it's a relatively new command, so why
> shouldn't we validate it strictly?
That is why this patch is RFC: see cover email :)
Sure, I can fix hostapd instead. Could you point me at some good
starting point to look at ? Are there any user-space tools that
started to use strict validation ?
P.S.
If you are ok with the second patch, then could you just take it
from this series ? Or should I resubmit ?
Regards,
Sergey
On Thu, 2020-02-13 at 11:13 +0000, Sergey Matyukevich wrote:
> On Thu, Feb 13, 2020 at 10:12:47AM +0100, Johannes Berg wrote:
> > [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.
> >
> > On Thu, 2020-02-13 at 09:07 +0000, Sergey Matyukevich wrote:
> > > Do not perform strict validation of UPDATE_OWE command.
> > > Otherwise, kernel rejects command executed by hostapd.
> >
> > Can't we fix hostapd? I mean, it's a relatively new command, so why
> > shouldn't we validate it strictly?
>
> That is why this patch is RFC: see cover email :)
Ah, was on the phone and hadn't read that yet ...
> Sure, I can fix hostapd instead. Could you point me at some good
> starting point to look at ? Are there any user-space tools that
> started to use strict validation ?
It's not really opt-in or not, it's entirely a kernel choice.
> P.S.
> If you are ok with the second patch, then could you just take it
> from this series ? Or should I resubmit ?
I can just take it.
johannes
> On Thu, 2020-02-13 at 11:13 +0000, Sergey Matyukevich wrote:
> > On Thu, Feb 13, 2020 at 10:12:47AM +0100, Johannes Berg wrote:
> > > [External Email]: This email arrived from an external source - Please exercise caution when opening any attachments or clicking on links.
> > >
> > > On Thu, 2020-02-13 at 09:07 +0000, Sergey Matyukevich wrote:
> > > > Do not perform strict validation of UPDATE_OWE command.
> > > > Otherwise, kernel rejects command executed by hostapd.
> > >
> > > Can't we fix hostapd? I mean, it's a relatively new command, so why
> > > shouldn't we validate it strictly?
> >
> > That is why this patch is RFC: see cover email :)
>
> Ah, was on the phone and hadn't read that yet ...
>
> > Sure, I can fix hostapd instead. Could you point me at some good
> > starting point to look at ? Are there any user-space tools that
> > started to use strict validation ?
>
> It's not really opt-in or not, it's entirely a kernel choice.
I mean, I don't know what userspace is supposed to do in the case,
when kernel is doing strict validation. So I was asking about any
pointers to docs or userspace tools that already do netlink
machinery appropriately.
> > P.S.
> > If you are ok with the second patch, then could you just take it
> > from this series ? Or should I resubmit ?
>
> I can just take it.
Ok
Regards,
Sergey
On Thu, 2020-02-13 at 11:21 +0000, Sergey Matyukevich wrote:
> >
> > > Sure, I can fix hostapd instead. Could you point me at some good
> > > starting point to look at ? Are there any user-space tools that
> > > started to use strict validation ?
> >
> > It's not really opt-in or not, it's entirely a kernel choice.
>
> I mean, I don't know what userspace is supposed to do in the case,
> when kernel is doing strict validation. So I was asking about any
> pointers to docs or userspace tools that already do netlink
> machinery appropriately.
Userspace is just supposed to create well-formed messages :-)
But ... it really is a kernel bug. The nl80211_policy is missing an
entry for NL80211_ATTR_STATUS_CODE, so for *strict* commands, it's
assumed to not be supported. Need to add something like
[NL80211_ATTR_STATUS_CODE] = { .type = NLA_U16, },
to the nl80211_policy, or perhaps with a range indicating that 0 isn't
valid or something.
johannes
> On Thu, 2020-02-13 at 11:21 +0000, Sergey Matyukevich wrote:
> > >
> > > > Sure, I can fix hostapd instead. Could you point me at some good
> > > > starting point to look at ? Are there any user-space tools that
> > > > started to use strict validation ?
> > >
> > > It's not really opt-in or not, it's entirely a kernel choice.
> >
> > I mean, I don't know what userspace is supposed to do in the case,
> > when kernel is doing strict validation. So I was asking about any
> > pointers to docs or userspace tools that already do netlink
> > machinery appropriately.
>
> Userspace is just supposed to create well-formed messages :-)
>
> But ... it really is a kernel bug. The nl80211_policy is missing an
> entry for NL80211_ATTR_STATUS_CODE, so for *strict* commands, it's
> assumed to not be supported. Need to add something like
>
> [NL80211_ATTR_STATUS_CODE] = { .type = NLA_U16, },
>
> to the nl80211_policy, or perhaps with a range indicating that 0 isn't
> valid or something.
Great. Thanks for explanation. Would you mind if I send a fix ?
Or now you have your own plans for this ?
Regards,
Sergey
On Thu, 2020-02-13 at 11:43 +0000, Sergey Matyukevich wrote:
> >
> Great. Thanks for explanation. Would you mind if I send a fix ?
> Or now you have your own plans for this ?
Please do :)
johannes