Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: kvalo=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 6B5B3C4360D
From:   Kalle Valo <kvalo@codeaurora.org>
To:     "Grumbach\, Emmanuel" <emmanuel.grumbach@intel.com>
Cc:     Emmanuel Grumbach <egrumbach@gmail.com>,
        "Coelho\, Luciano" <luciano.coelho@intel.com>,
        linux-wireless <linux-wireless@vger.kernel.org>,
        "Beker\, Ayala" <ayala.beker@intel.com>
Subject: Re: [PATCH v3 4/4] iwlwifi: mvm: add vendor commands needed for iwlmei
References: <20210623141033.27475-1-emmanuel.grumbach@intel.com>
        <20210623141033.27475-4-emmanuel.grumbach@intel.com>
        <87fsx7i416.fsf@codeaurora.org>
        <CANUX_P3HWWBkeHHSw+-wdQEBFNF1V+GWRDFiEerH7NhksRvOzA@mail.gmail.com>
        <87o8acc8v1.fsf@codeaurora.org>
        <SA0PR11MB4752D9B34C2A60B85CA3E5F3F2F49@SA0PR11MB4752.namprd11.prod.outlook.com>
Date:   Mon, 18 Oct 2021 14:27:44 +0300
In-Reply-To: <SA0PR11MB4752D9B34C2A60B85CA3E5F3F2F49@SA0PR11MB4752.namprd11.prod.outlook.com>
        (Emmanuel Grumbach's message of "Sat, 7 Aug 2021 18:34:34 +0000")
Message-ID: <87zgr6tvwv.fsf@codeaurora.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

"Grumbach, Emmanuel" <emmanuel.grumbach@intel.com> writes:

>  
>> > On Thu, Jun 24, 2021 at 8:13 PM Kalle Valo <kvalo@codeaurora.org> wrote:
>> >>
>> >> Emmanuel Grumbach <emmanuel.grumbach@intel.com> writes:
>> >>
>> >> > Add the vendor commands that must be used by the network manager
>> to
>> >> > allow proper operation of iwlmei.
>> >> >
>> >> > * Send information on the AP CSME is connected to
>> >> > * Notify the userspace when roaming is forbidden
>> >> > * Allow the userspace to require ownership
>> >> >
>> >> > Co-Developed-by: Ayala Beker <ayala.beker@intel.com>
>> >> > Signed-off-by: Emmanuel Grumbach
>> <emmanuel.grumbach@intel.com>
>> >> > ---
>> >> >  drivers/net/wireless/intel/iwlwifi/Kconfig    |  11 ++
>> >> >  .../net/wireless/intel/iwlwifi/mvm/Makefile   |   1 +
>> >> >  .../net/wireless/intel/iwlwifi/mvm/mac80211.c |   2 +
>> >> >  drivers/net/wireless/intel/iwlwifi/mvm/mvm.h  |   9 +-
>> >> >  .../wireless/intel/iwlwifi/mvm/vendor-cmd.c   | 186
>> ++++++++++++++++++
>> >> >  5 files changed, 203 insertions(+), 6 deletions(-)  create mode
>> >> > 100644 drivers/net/wireless/intel/iwlwifi/mvm/vendor-cmd.c
>> >> >
>> >> > diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig
>> >> > b/drivers/net/wireless/intel/iwlwifi/Kconfig
>> >> > index 629aaa26a230..f91516d08b28 100644
>> >> > --- a/drivers/net/wireless/intel/iwlwifi/Kconfig
>> >> > +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
>> >> > @@ -92,11 +92,22 @@ config IWLWIFI_BCAST_FILTERING
>> >> >         If unsure, don't enable this option, as some programs might
>> >> >         expect incoming broadcasts for their normal operations.
>> >> >
>> >> > +config IWLMVM_VENDOR_CMDS
>> >> > +     bool "Enable vendor commands"
>> >> > +     depends on IWLMVM
>> >> > +     help
>> >> > +       This option enables support for vendor commands, including some
>> >> > +       that don't have their own Kconfig option. Other Kconfig options
>> >> > +       depend on this one as well.
>> >> > +
>> >> > +       This is not enabled by default, if unsure, say N.
>> >>
>> >> Why do we need a new Kconfig option? Why not always include it in the
>> >> compilation?
>> >
>> > I expect 99.9% of the users to want to disable this.VENDOR_CMDS adds a
>> > user space API and in a sense, it increases the attack surface. You
>> > can claim that I can reuse the IWLMEI Kconfig option, which is true,
>> > but we have other features that need VENDOR_CMDS that are not (yet)
>> > upstream. So the idea here is that any feature that needs the
>> > VENDOR_CMDS will select it and if none of them are enabled (for 99.9%
>> > of the use cases), then, we would disable VENDOR_CMDS and decrease
>> the
>> > attack surface.
>> >
>> > Makes sense?
>> 
>> How do you prevent users or distros from enabling the feature? They can be
>> in a hurry, lazy or not caring and enable the feature anyway. So no, I'm not
>> really buying this. If the interface is not secure it should not be in upstream, I
>> think only exception to this is the nl80211 testmode interface which is for lab
>> or similar use.
>> 
>
> So what do you want? To make it depend on IWLMEI Kconfig knob and not
> add the VENDOR_CMDS one? Fine.

Yes, that sounds like a good idea. And I saw you did that already in v6.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches