linux-kernel - Re: [PATCH] Bluetooth: btusb: add a reject table to disable msft

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 19 Aug 2021 16:46:16 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Koba Ko <koba.ko@...onical.com>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "open list:BLUETOOTH SUBSYSTEM" <linux-bluetooth@...r.kernel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: btusb: add a reject table to disable msft

Hi Koba,

> With Intel AC9560, follow this scenario and can't turn on bt since.
> 1. turn off BT
> 2. then suspend&resume multiple times
> 3. turn on BT
> 
> Get this error message after turn on bt.
> [ 877.194032] Bluetooth: hci0: urb 0000000061b9a002 failed to resubmit (113)
> [ 886.941327] Bluetooth: hci0: Failed to read MSFT supported features (-110)
> 
> Remove msft from compilation would be helpful.
> Turn off msft would be also helpful.
> 
> As per Intel's comment, For AC9560, in JSL the hw_variant is 0x13.
> In GLK, the hw_variant is 0x11. can't use hw_variant to filter for
> AC9560.
> Only AC9560 encounter this issue, so add a reject table to
> disable msft for AC9560.
> 
> Signed-off-by: Koba Ko <koba.ko@...onical.com>
> ---
> drivers/bluetooth/btusb.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index a9855a2dd561..3c131fd40869 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -479,6 +479,11 @@ static const struct usb_device_id blacklist_table[] = {
> 	{ }	/* Terminating entry */
> };
> 
> +static const struct usb_device_id msft_rej_table[] = {
> +	{ USB_DEVICE(0x8087, 0x0aaa) },
> +	{ }	/* Terminating entry */
> +};
> +
> /* The Bluetooth USB module build into some devices needs to be reset on resume,
>  * this is a problem with the platform (likely shutting off all power) not with
>  * the module itself. So we use a DMI list to match known broken platforms.
> @@ -2851,6 +2856,7 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
> 	char ddcname[64];
> 	int err;
> 	struct intel_debug_features features;
> +	struct usb_device_id *match;
> 
> 	BT_DBG("%s", hdev->name);
> 
> @@ -2928,7 +2934,9 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
> 	case 0x12:	/* ThP */
> 	case 0x13:	/* HrP */
> 	case 0x14:	/* CcP */
> -		hci_set_msft_opcode(hdev, 0xFC1E);
> +		match = usb_match_id(data->intf, msft_rej_table);
> +		if (!match)
> +			hci_set_msft_opcode(hdev, 0xFC1E);
> 		break;
> 	}

actually _no_, we are not doing this either.

We just got rid of the per USB VID:PID mess around Intel hardware and I don’t want to add it back. The Intel guys need to figure this out, otherwise, we remove 0x14 /* CcP */ from the list of MSFT extension support.

Regards

Marcel