linux-kernel - Re: [PATCH v5 3/3] Bluetooth: btusb: Indicate Microsoft vendor extension for Intel 9160/9260

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <3361CF04-0C56-4787-9A74-99664DCB4312@holtmann.org>
Date:   Mon, 6 Apr 2020 08:14:41 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Miao-chen Chou <mcchou@...omium.org>
Cc:     Bluetooth Kernel Mailing List <linux-bluetooth@...r.kernel.org>,
        Alain Michaud <alainm@...omium.org>,
        Luiz Augusto von Dentz <luiz.von.dentz@...el.com>,
        Johan Hedberg <johan.hedberg@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] Bluetooth: btusb: Indicate Microsoft vendor
 extension for Intel 9160/9260

Hi Miao-chen,

> This adds a bit mask of driver_info for Microsoft vendor extension and
> indicates the support for Intel 9160/9260. This was verified with Intel
> ThunderPeak BT controller where msft_opcode is 0xFC1E.
> 
> Signed-off-by: Marcel Holtmann <marcel@...tmann.org>
> Signed-off-by: Miao-chen Chou <mcchou@...omium.org>
> ---
> 
> Changes in v5:
> - Extract the changes on btusb as a different commit.
> 
> Changes in v4:
> - Introduce CONFIG_BT_MSFTEXT as a starting point of providing a
> framework to use Microsoft extension
> - Create include/net/bluetooth/msft.h and net/bluetooth/msft.c to
> facilitate functions of Microsoft extension.
> 
> Changes in v3:
> - Create net/bluetooth/msft.c with struct msft_vnd_ext defined internally
> and change the hdev->msft_ext field to void*.
> - Define and expose msft_vnd_ext_set_opcode() for btusb use.
> - Init hdev->msft_ext in hci_alloc_dev() and deinit it in hci_free_dev().
> 
> Changes in v2:
> - Define struct msft_vnd_ext and add a field of this type to struct
> hci_dev to facilitate the support of Microsoft vendor extension.
> 
> drivers/bluetooth/btusb.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index 3bdec42c96123..f73ad18c04559 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -20,6 +20,7 @@
> 
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> +#include <net/bluetooth/msft.h>
> 
> #include "btintel.h"
> #include "btbcm.h"
> @@ -58,6 +59,7 @@ static struct usb_driver btusb_driver;
> #define BTUSB_CW6622		0x100000
> #define BTUSB_MEDIATEK		0x200000
> #define BTUSB_WIDEBAND_SPEECH	0x400000
> +#define BTUSB_MSFT_VND_EXT	0x800000
> 
> static const struct usb_device_id btusb_table[] = {
> 	/* Generic Bluetooth USB device */
> @@ -335,7 +337,8 @@ static const struct usb_device_id blacklist_table[] = {
> 
> 	/* Intel Bluetooth devices */
> 	{ USB_DEVICE(0x8087, 0x0025), .driver_info = BTUSB_INTEL_NEW |
> -						     BTUSB_WIDEBAND_SPEECH },
> +						     BTUSB_WIDEBAND_SPEECH |
> +						     BTUSB_MSFT_VND_EXT },
> 	{ USB_DEVICE(0x8087, 0x0026), .driver_info = BTUSB_INTEL_NEW |
> 						     BTUSB_WIDEBAND_SPEECH },
> 	{ USB_DEVICE(0x8087, 0x0029), .driver_info = BTUSB_INTEL_NEW |
> @@ -3800,6 +3803,12 @@ static int btusb_probe(struct usb_interface *intf,
> 		set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
> 		set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
> 		set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
> +
> +		/* All Intel controllers that support the Microsoft
> +		 * vendor extension are using 0xFC1E for VsMsftOpCode.
> +		 */
> +		if (id->driver_info & BTUSB_MSFT_VND_EXT)
> +			msft_set_opcode(hdev, 0xFC1E);

I decided to actually set the MSFT extension support in the btusb_setup_intel_new handler based on our firmware version information. I think that this will be better than USB products IDs. We can revisit this later, but for now, this should be enough.

Johan also applied the whole series and you should base your next steps on bluetooth-next.

Regards

Marcel