linux-kernel - Re: [PATCH] Bluetooth: Apply initial command workaround for more Intel chips

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: <9C896BDF-FBB1-4C3D-B98E-79D818191DBC@holtmann.org>
Date:   Fri, 3 Dec 2021 22:18:06 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Paul Menzel <pmenzel@...gen.mpg.de>,
        Johan Hedberg <johan.hedberg@...il.com>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Tedd Ho-Jeong An <tedd.an@...el.com>,
        linux-kernel@...r.kernel.org, linux-bluetooth@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: Apply initial command workaround for more
 Intel chips

Hi Takashi,

>>>>> It seems that a few more Intel chips require the workaround for the
>>>>> broken initial command.  At least, per openSUSE Bugzilla reports,
>>>>> 8087:0a2a and 8087:0026 need BTUSB_INTEL_BROKEN_INITIAL_NCMD flag.
>>>>> 
>>>>> Fixes: 83f2dafe2a62 ("Bluetooth: btintel: Refactoring setup routine for legacy ROM sku")
>>>>> Buglink: https://bugzilla.opensuse.org/show_bug.cgi?id=1193124
>>>>> Signed-off-by: Takashi Iwai <tiwai@...e.de>
>>>>> 
>>>> 
>>>> […]
>>>> 
>>>> I have a Dell Latitude E7250 with
>>>> 
>>>>     Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
>>>> 
>>>> and Bluetooth seems to work fine minus some Linux warnings [1] and a
>>>> problem transferring greater than some bytes files with the Nokia N9
>>>> [2].
>>>> 
>>>> Linux 5.16-rc3, Dell Inc. Latitude E7250/0TVD2T, BIOS A19 01/23/2018:
>>>> 
>>>> ```
>>>> $ sudo dmesg | grep -i bluet
>>>> [    8.173417] calling  bt_init+0x0/0xb3 [bluetooth] @ 301
>>>> [    8.173439] Bluetooth: Core ver 2.22
>>>> [    8.173463] NET: Registered PF_BLUETOOTH protocol family
>>>> [    8.173464] Bluetooth: HCI device and connection manager initialized
>>>> [    8.173467] Bluetooth: HCI socket layer initialized
>>>> [    8.173470] Bluetooth: L2CAP socket layer initialized
>>>> [    8.173473] Bluetooth: SCO socket layer initialized
>>>> [    8.173475] initcall bt_init+0x0/0xb3 [bluetooth] returned 0 after 35 usecs
>>>> [    8.216875] Bluetooth: hci0: Legacy ROM 2.5 revision 1.0 build 3 week 17 2014
>>>> [    8.233515] bluetooth hci0: firmware: direct-loading firmware intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [    8.233520] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq
>>>> [    8.540884] Bluetooth: hci0: unexpected event for opcode 0xfc2f
>>>> [    8.558942] Bluetooth: hci0: Intel BT fw patch 0x32 completed & activated
>>>> ```
>>> 
>>> Thanks, so this seems depending on the hardware, maybe a subtle
>>> difference matters.  As far as I read the code changes, the workaround
>>> was applied in the past unconditionally, so it must be fairly safe
>>> even if the chip works as is.
>> 
>> Maybe add that to the commit message?
> 
> Maybe, if the upstream agrees with that.  More comments needed from
> Intel, as it's a kind of black magic.
> 
>>> Or, for avoiding the unnecessarily application of the workaround,
>>> should it be changed as a fallback after the failure at the first
>>> try...?
>> 
>> Reading through the openSUSE Bugzilla issue, the failure is:
>> 
>>    Bluetooth: hci0: Reading Intel version command failed (-110)
>>    Bluetooth: hci0: command 0xfc05 tx timeout
>> 
>> I couldn’t find the report for 8087:0a2a in the issue.
> 
> There two different machines in the report.
> 
>> Can you check,
>> what firmware is used?
> 
> It's the place before loading the firmware, so the firmware version
> doesn't matter.

I want to apply this quirk to as little devices as possible. It is one of these quirks we have to hardcode per USB VID:PID since we can’t auto-detect which boot loader is faulty.

So before I blacklist them, we better get a good understand of which they are. Can you include a btmon trace for that part. You most likely have to blacklist btusb.ko, start btmon and then load btusb.ko manually. One with and one without the quirk. And add that to the commit message.

We then try to find that module internally. It must be some SKU that we didn’t have in our test rack.

Regards

Marcel