1. 21 8月, 2019 1 次提交
  2. 31 7月, 2019 3 次提交
  3. 29 7月, 2019 2 次提交
  4. 26 7月, 2019 2 次提交
  5. 14 6月, 2019 6 次提交
  6. 29 5月, 2019 1 次提交
  7. 28 5月, 2019 2 次提交
  8. 24 5月, 2019 1 次提交
    • M
      {nl,mac}80211: allow 4addr AP operation on crypto controlled devices · 33d915d9
      Manikanta Pubbisetty 提交于
      As per the current design, in the case of sw crypto controlled devices,
      it is the device which advertises the support for AP/VLAN iftype based
      on it's ability to tranmsit packets encrypted in software
      (In VLAN functionality, group traffic generated for a specific
      VLAN group is always encrypted in software). Commit db3bdcb9
      ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      has introduced this change.
      
      Since 4addr AP operation also uses AP/VLAN iftype, this conditional
      way of advertising AP/VLAN support has broken 4addr AP mode operation on
      crypto controlled devices which do not support VLAN functionality.
      
      In the case of ath10k driver, not all firmwares have support for VLAN
      functionality but all can support 4addr AP operation. Because AP/VLAN
      support is not advertised for these devices, 4addr AP operations are
      also blocked.
      
      Fix this by allowing 4addr operation on devices which do not support
      AP/VLAN iftype but can support 4addr AP operation (decision is based on
      the wiphy flag WIPHY_FLAG_4ADDR_AP).
      
      Cc: stable@vger.kernel.org
      Fixes: db3bdcb9 ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      33d915d9
  9. 21 5月, 2019 1 次提交
  10. 28 4月, 2019 3 次提交
    • J
      genetlink: optionally validate strictly/dumps · ef6243ac
      Johannes Berg 提交于
      Add options to strictly validate messages and dump messages,
      sometimes perhaps validating dump messages non-strictly may
      be required, so add an option for that as well.
      
      Since none of this can really be applied to existing commands,
      set the options everwhere using the following spatch:
      
          @@
          identifier ops;
          expression X;
          @@
          struct genl_ops ops[] = {
          ...,
           {
                  .cmd = X,
          +       .validate = GENL_DONT_VALIDATE_STRICT | GENL_DONT_VALIDATE_DUMP,
                  ...
           },
          ...
          };
      
      For new commands one should just not copy the .validate 'opt-out'
      flags and thus get strict validation.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ef6243ac
    • J
      netlink: make validation more configurable for future strictness · 8cb08174
      Johannes Berg 提交于
      We currently have two levels of strict validation:
      
       1) liberal (default)
           - undefined (type >= max) & NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
           - garbage at end of message accepted
       2) strict (opt-in)
           - NLA_UNSPEC attributes accepted
           - attribute length >= expected accepted
      
      Split out parsing strictness into four different options:
       * TRAILING     - check that there's no trailing data after parsing
                        attributes (in message or nested)
       * MAXTYPE      - reject attrs > max known type
       * UNSPEC       - reject attributes with NLA_UNSPEC policy entries
       * STRICT_ATTRS - strictly validate attribute size
      
      The default for future things should be *everything*.
      The current *_strict() is a combination of TRAILING and MAXTYPE,
      and is renamed to _deprecated_strict().
      The current regular parsing has none of this, and is renamed to
      *_parse_deprecated().
      
      Additionally it allows us to selectively set one of the new flags
      even on old policies. Notably, the UNSPEC flag could be useful in
      this case, since it can be arranged (by filling in the policy) to
      not be an incompatible userspace ABI change, but would then going
      forward prevent forgetting attribute entries. Similar can apply
      to the POLICY flag.
      
      We end up with the following renames:
       * nla_parse           -> nla_parse_deprecated
       * nla_parse_strict    -> nla_parse_deprecated_strict
       * nlmsg_parse         -> nlmsg_parse_deprecated
       * nlmsg_parse_strict  -> nlmsg_parse_deprecated_strict
       * nla_parse_nested    -> nla_parse_nested_deprecated
       * nla_validate_nested -> nla_validate_nested_deprecated
      
      Using spatch, of course:
          @@
          expression TB, MAX, HEAD, LEN, POL, EXT;
          @@
          -nla_parse(TB, MAX, HEAD, LEN, POL, EXT)
          +nla_parse_deprecated(TB, MAX, HEAD, LEN, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, TB, MAX, POL, EXT;
          @@
          -nlmsg_parse_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
          +nlmsg_parse_deprecated_strict(NLH, HDRLEN, TB, MAX, POL, EXT)
      
          @@
          expression TB, MAX, NLA, POL, EXT;
          @@
          -nla_parse_nested(TB, MAX, NLA, POL, EXT)
          +nla_parse_nested_deprecated(TB, MAX, NLA, POL, EXT)
      
          @@
          expression START, MAX, POL, EXT;
          @@
          -nla_validate_nested(START, MAX, POL, EXT)
          +nla_validate_nested_deprecated(START, MAX, POL, EXT)
      
          @@
          expression NLH, HDRLEN, MAX, POL, EXT;
          @@
          -nlmsg_validate(NLH, HDRLEN, MAX, POL, EXT)
          +nlmsg_validate_deprecated(NLH, HDRLEN, MAX, POL, EXT)
      
      For this patch, don't actually add the strict, non-renamed versions
      yet so that it breaks compile if I get it wrong.
      
      Also, while at it, make nla_validate and nla_parse go down to a
      common __nla_validate_parse() function to avoid code duplication.
      
      Ultimately, this allows us to have very strict validation for every
      new caller of nla_parse()/nlmsg_parse() etc as re-introduced in the
      next patch, while existing things will continue to work as is.
      
      In effect then, this adds fully strict validation for any new command.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8cb08174
    • M
      netlink: make nla_nest_start() add NLA_F_NESTED flag · ae0be8de
      Michal Kubecek 提交于
      Even if the NLA_F_NESTED flag was introduced more than 11 years ago, most
      netlink based interfaces (including recently added ones) are still not
      setting it in kernel generated messages. Without the flag, message parsers
      not aware of attribute semantics (e.g. wireshark dissector or libmnl's
      mnl_nlmsg_fprintf()) cannot recognize nested attributes and won't display
      the structure of their contents.
      
      Unfortunately we cannot just add the flag everywhere as there may be
      userspace applications which check nlattr::nla_type directly rather than
      through a helper masking out the flags. Therefore the patch renames
      nla_nest_start() to nla_nest_start_noflag() and introduces nla_nest_start()
      as a wrapper adding NLA_F_NESTED. The calls which add NLA_F_NESTED manually
      are rewritten to use nla_nest_start().
      
      Except for changes in include/net/netlink.h, the patch was generated using
      this semantic patch:
      
      @@ expression E1, E2; @@
      -nla_nest_start(E1, E2)
      +nla_nest_start_noflag(E1, E2)
      
      @@ expression E1, E2; @@
      -nla_nest_start_noflag(E1, E2 | NLA_F_NESTED)
      +nla_nest_start(E1, E2)
      Signed-off-by: NMichal Kubecek <mkubecek@suse.cz>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ae0be8de
  11. 26 4月, 2019 6 次提交
  12. 08 4月, 2019 4 次提交
    • S
      cfg80211/nl80211: Offload OWE processing to user space in AP mode · cb74e977
      Sunil Dutt 提交于
      This interface allows the host driver to offload OWE processing
      to user space. This intends to support OWE (Opportunistic Wireless
      Encryption) AKM by the drivers that implement SME but rely on the
      user space for the cryptographic/OWE processing in AP mode. Such
      drivers are not capable of processing/deriving the DH IE.
      
      A new NL80211 command - NL80211_CMD_UPDATE_OWE_INFO is introduced
      to send the request/event between the host driver and user space.
      
      Driver shall provide the OWE info (MAC address and DH IE) of
      the peer to user space for cryptographic processing of the DH IE
      through the event. Accordingly, the user space shall update the
      OWE info/DH IE to the driver.
      
      Following is the sequence in AP mode for OWE authentication.
      
      Driver passes the OWE info obtained from the peer in the
      Association Request to the user space through the event
      cfg80211_update_owe_info_event. User space shall process the
      OWE info received and generate new OWE info. This OWE info is
      passed to the driver through NL80211_CMD_UPDATE_OWE_INFO
      request. Driver eventually uses this OWE info to send the
      Association Response to the peer.
      
      This OWE info in the command interface carries the IEs that include
      PMKID of the peer if the PMKSA is still valid or an updated DH IE
      for generating a new PMKSA with the peer.
      Signed-off-by: NLiangwei Dong <liangwei@codeaurora.org>
      Signed-off-by: NSunil Dutt <usdutt@codeaurora.org>
      Signed-off-by: NSrinivas Dasari <dasaris@codeaurora.org>
      [remove policy initialization - no longer exists]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      cb74e977
    • N
      mac80211: Add support for NL80211_STA_INFO_AIRTIME_LINK_METRIC · ab60633c
      Narayanraddi Masti 提交于
      Add support for mesh airtime link metric attribute
      NL80211_STA_INFO_AIRTIME_LINK_METRIC.
      Signed-off-by: NNarayanraddi Masti <team.nmasti@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ab60633c
    • V
      nl80211/cfg80211: Specify band specific min RSSI thresholds with sched scan · 1e1b11b6
      vamsi krishna 提交于
      This commit adds the support to specify the RSSI thresholds per
      band for each match set. This enhances the current behavior which
      specifies a single rssi_threshold across all the bands by
      introducing the rssi_threshold_per_band. These per band rssi
      thresholds are referred through NL80211_BAND_* (enum nl80211_band)
      variables  as attribute types. Such attributes/values per each
      band are nested through NL80211_ATTR_SCHED_SCAN_MIN_RSSI.
      These band specific rssi thresholds shall take precedence over
      the current rssi_thold per match set.
      Drivers indicate this support through
      %NL80211_EXT_FEATURE_SCHED_SCAN_BAND_SPECIFIC_RSSI_THOLD.
      These per band rssi attributes/values does not specify
      "default RSSI filter" as done by
      NL80211_SCHED_SCAN_MATCH_ATTR_RSSI to stay backward compatible.
      That said, these per band rssi values have to be specified for
      the corresponding matchset.
      Signed-off-by: Nvamsi krishna <vamsin@codeaurora.org>
      Signed-off-by: NSrinivas Dasari <dasaris@codeaurora.org>
      [rebase on refactoring, add policy]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1e1b11b6
    • J
      nl80211: reindent some sched scan code · d39f3b4f
      Johannes Berg 提交于
      The sched scan code here is really deep - avoid one level
      of indentation by short-circuiting the loop instead of
      putting everything into the if block.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d39f3b4f
  13. 29 3月, 2019 1 次提交
  14. 22 3月, 2019 1 次提交
    • J
      genetlink: make policy common to family · 3b0f31f2
      Johannes Berg 提交于
      Since maxattr is common, the policy can't really differ sanely,
      so make it common as well.
      
      The only user that did in fact manage to make a non-common policy
      is taskstats, which has to be really careful about it (since it's
      still using a common maxattr!). This is no longer supported, but
      we can fake it using pre_doit.
      
      This reduces the size of e.g. nl80211.o (which has lots of commands):
      
         text	   data	    bss	    dec	    hex	filename
       398745	  14323	   2240	 415308	  6564c	net/wireless/nl80211.o (before)
       397913	  14331	   2240	 414484	  65314	net/wireless/nl80211.o (after)
      --------------------------------
         -832      +8       0    -824
      
      Which is obviously just 8 bytes for each command, and an added 8
      bytes for the new policy pointer. I'm not sure why the ops list is
      counted as .text though.
      
      Most of the code transformations were done using the following spatch:
          @ops@
          identifier OPS;
          expression POLICY;
          @@
          struct genl_ops OPS[] = {
          ...,
           {
          -	.policy = POLICY,
           },
          ...
          };
      
          @@
          identifier ops.OPS;
          expression ops.POLICY;
          identifier fam;
          expression M;
          @@
          struct genl_family fam = {
                  .ops = OPS,
                  .maxattr = M,
          +       .policy = POLICY,
                  ...
          };
      
      This also gets rid of devlink_nl_cmd_region_read_dumpit() accessing
      the cb->data as ops, which we want to change in a later genl patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b0f31f2
  15. 22 2月, 2019 2 次提交
  16. 11 2月, 2019 2 次提交
  17. 08 2月, 2019 1 次提交
  18. 01 2月, 2019 1 次提交
    • J
      netlink: reduce NLA_POLICY_NESTED{,_ARRAY} arguments · 23323289
      Johannes Berg 提交于
      In typical cases, there's no need to pass both the maxattr
      and the policy array pointer, as the maxattr should just be
      ARRAY_SIZE(policy) - 1. Therefore, to be less error prone,
      just remove the maxattr argument from the default macros
      and deduce the size accordingly.
      
      Leave the original macros with a leading underscore to use
      here and in case somebody needs to pass a policy pointer
      where the policy isn't declared in the same place and thus
      ARRAY_SIZE() cannot be used.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      23323289