linux-kernel - Re: [PATCH v2 4/4] Bluetooth: Queue a HCI power-off command before rfkilling adapters

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: <CABBYNZ+uy50g2CSJ37DL63ycSJc96Xegdjcr6N2weJfCiGO_Aw@mail.gmail.com>
Date: Tue, 2 Jan 2024 13:31:55 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Jonas Dreßler <verdre@...d.nl>
Cc: Marcel Holtmann <marcel@...tmann.org>, Johan Hedberg <johan.hedberg@...il.com>, asahi@...ts.linux.dev, 
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH v2 4/4] Bluetooth: Queue a HCI power-off command before
 rfkilling adapters

Hi Jonas,

On Tue, Jan 2, 2024 at 1:19 PM Jonas Dreßler <verdre@...d.nl> wrote:
>
> On a lot of platforms (at least the MS Surface devices, M1 macbooks, and
> a few ThinkPads) firmware doesn't do its job when rfkilling a device
> and the bluetooth adapter is not actually shut down on rfkill. This leads
> to connected devices remaining in connected state and the bluetooth
> connection eventually timing out after rfkilling an adapter.
>
> Use the rfkill hook in the HCI driver to actually power the device off
> before rfkilling it.
>
> Note that the wifi subsystem is doing something similar by calling
> cfg80211_shutdown_all_interfaces()
> in it's rfkill set_block callback (see cfg80211_rfkill_set_block).

So the rfkill is supposed to be wait for cleanup, not a forceful
shutdown of RF traffic? I assume it would be the later since to do a
proper cleanup that could cause more RF traffic while the current
assumption was to stop all traffic and then call hdev->shutdown to
ensure the driver does shutdown the RF traffic, perhaps this
assumption has changed over time since interrupting the RF traffic may
cause what you just described because the remote end will have to rely
on link-loss logic to detect the connection has been terminated.

> Signed-off-by: Jonas Dreßler <verdre@...d.nl>
> ---
>  net/bluetooth/hci_core.c | 33 ++++++++++++++++++++++++++++++---
>  1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index 1ec83985f..1c91d02f7 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -543,6 +543,23 @@ int hci_dev_open(__u16 dev)
>         return err;
>  }
>
> +static int set_powered_off_sync(struct hci_dev *hdev, void *data)
> +{
> +       return hci_set_powered_sync(hdev, false);
> +}
> +
> +static void set_powered_off_sync_complete(struct hci_dev *hdev, void *data, int err)
> +{
> +       if (err)
> +               bt_dev_err(hdev, "Powering HCI device off before rfkilling failed (%d)", err);
> +}
> +
> +static int hci_dev_do_poweroff(struct hci_dev *hdev)
> +{
> +       return hci_cmd_sync_queue(hdev, set_powered_off_sync,
> +                                 NULL, set_powered_off_sync_complete);
> +}
> +
>  int hci_dev_do_close(struct hci_dev *hdev)
>  {
>         int err;
> @@ -943,17 +960,27 @@ int hci_get_dev_info(void __user *arg)
>  static int hci_rfkill_set_block(void *data, bool blocked)
>  {
>         struct hci_dev *hdev = data;
> +       int err;
>
>         BT_DBG("%p name %s blocked %d", hdev, hdev->name, blocked);
>
>         if (hci_dev_test_flag(hdev, HCI_USER_CHANNEL))
>                 return -EBUSY;
>
> +       if (blocked == hci_dev_test_flag(hdev, HCI_RFKILLED))
> +               return 0;
> +
>         if (blocked) {
> -               hci_dev_set_flag(hdev, HCI_RFKILLED);
>                 if (!hci_dev_test_flag(hdev, HCI_SETUP) &&
> -                   !hci_dev_test_flag(hdev, HCI_CONFIG))
> -                       hci_dev_do_close(hdev);
> +                   !hci_dev_test_flag(hdev, HCI_CONFIG)) {
> +                       err = hci_dev_do_poweroff(hdev);
> +                       if (err) {
> +                               bt_dev_err(hdev, "Powering off device before rfkilling failed (%d)",
> +                                          err);
> +                       }

You already have the error printed on set_powered_off_sync_complete
not sure why you have it here as well.

> +               }
> +
> +               hci_dev_set_flag(hdev, HCI_RFKILLED);

Before we used to set the HCI_RFKILLED beforehand, is this change
really intended or not? I think we should keep doing it ahead of power
off sequence since we can probably use it to ignore if there are any
errors on the cleanup, etc.

>         } else {
>                 hci_dev_clear_flag(hdev, HCI_RFKILLED);
>         }
> --
> 2.43.0
>


-- 
Luiz Augusto von Dentz