linux-kernel - Re: [PATCH 2/2] Bluetooth: btusb: Disable LE Advertising on system suspend

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] [day] [month] [year] [list]

Date:   Thu, 25 Apr 2019 18:35:14 +0200
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Kai Heng Feng <kai.heng.feng@...onical.com>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] Bluetooth: btusb: Disable LE Advertising on system
 suspend

Hi Kai-Heng,

>>> System may freeze during suspend, and it's caused by btusb early wakeup:
>>> 
>>> kernel: pci_pm_suspend(): hcd_pci_suspend+0x0/0x30 returns -16
>>> kernel: dpm_run_callback(): pci_pm_suspend+0x0/0x130 returns -16
>>> kernel: PM: Device 0000:00:14.0 failed to suspend async: error -16
>>> kernel: PM: Some devices failed to suspend, or early wake event detected
>>> kernel: usb usb1: usb resume
>>> kernel: hub 1-0:1.0: hub_resume
>>> kernel: usb usb1-port1: status 0507 change 0000
>>> kernel: usb usb1-port6: status 0103 change 0004
>>> kernel: usb usb1-port10: status 0107 change 0000
>>> 
>>> where btusb is connecte to usb1-port6.
>>> 
>>> The expirement shows that the early wakeup is caused by LE Advertising
>>> packet.
>>> 
>>> Disabling it via event mask can prevent the issue from happening.
>>> 
>>> BugLink: https://bugs.launchpad.net/bugs/1823029
>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
>>> ---
>>> drivers/bluetooth/btusb.c | 12 ++++++++++++
>>> 1 file changed, 12 insertions(+)
>>> 
>>> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
>>> index 10c8f9872ee5..f03fcf5687e4 100644
>>> --- a/drivers/bluetooth/btusb.c
>>> +++ b/drivers/bluetooth/btusb.c
>>> @@ -490,6 +490,7 @@ struct btusb_data {
>>> 	int (*setup_on_usb)(struct hci_dev *hdev);
>>> 
>>> 	int oob_wake_irq;   /* irq for out-of-band wake-on-bt */
>>> +	bool suspended;
>>> };
>>> 
>>> static inline void btusb_free_frags(struct btusb_data *data)
>>> @@ -3316,12 +3317,18 @@ static void btusb_disconnect(struct usb_interface *intf)
>>> static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
>>> {
>>> 	struct btusb_data *data = usb_get_intfdata(intf);
>>> +	struct hci_dev *hdev = data->hdev;
>>> 
>>> 	BT_DBG("intf %p", intf);
>>> 
>>> 	if (data->suspend_count++)
>>> 		return 0;
>>> 
>>> +	if (!PMSG_IS_AUTO(message)) {
>>> +		hci_disable_le_advertising(hdev);
>>> +		data->suspended = true;
>>> +	}
>>> +
>>> 	spin_lock_irq(&data->txlock);
>>> 	if (!(PMSG_IS_AUTO(message) && data->tx_in_flight)) {
>>> 		set_bit(BTUSB_SUSPENDING, &data->flags);
>>> @@ -3427,6 +3434,11 @@ static int btusb_resume(struct usb_interface *intf)
>>> 	spin_unlock_irq(&data->txlock);
>>> 	schedule_work(&data->work);
>>> 
>>> +	if (data->suspended) {
>>> +		hci_enable_le_advertising(hdev);
>>> +		data->suspended = false;
>>> +	}
>>> +
>>> 	return 0;
>> 
>> this is a clear NAK. Please stop hacking things.
>> 
>> Lets use hci_suspend_dev and hci_resume_dev and make it actually do something to disable the events for advertising.
> 
> Do you mean hci_disable_le_advertising() should be called by hci_suspend_dev(), which should be called by btusb_suspend()?
> 
> I’ve tried calling hci_suspend_dev() without disabling advertising, the issue still presents.

we have to define what the behavior of hci_suspend_dev is suppose to be. In general you want to wake up from LE Advertising, but most likely only ones that are passing the whitelist. Same goes for BR/EDR and HID wakeups btw.

Anyway this is the way to go since I will not allow doing any hacking from a HCI transport driver. And that is what btusb.c is. It is just a transport, it is not suppose to know anything about HCI internals unless told from the core.

Regards

Marcel