| 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
| ||
|
Message-ID: <CANFp7mW9tO9gEE2L7WGBNsoi9uyP1-k2t-OWnF3Qz=h0TW8WuQ@mail.gmail.com>
Date: Mon, 26 Sep 2022 17:20:59 -0700
From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: Abhishek Pandit-Subedi <abhishekpandit@...gle.com>,
linux-bluetooth@...r.kernel.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Johan Hedberg <johan.hedberg@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH v2] Bluetooth: Call shutdown for HCI_USER_CHANNEL
On Mon, Sep 26, 2022 at 5:10 PM Luiz Augusto von Dentz
<luiz.dentz@...il.com> wrote:
>
> Hi Abhishek,
>
> On Mon, Sep 26, 2022 at 4:44 PM Abhishek Pandit-Subedi
> <abhishekpandit@...gle.com> wrote:
> >
> > From: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> >
> > Some drivers depend on shutdown being called for proper operation.
> > Unset HCI_USER_CHANNEL and call the full close routine since shutdown is
> > complementary to setup.
> >
> > Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> > ---
> >
> > Using hci_qca, we can get the controller into a bad state simply by
> > trying to bind to userchannel twice (open+bind+close, then open+bind).
> > Without running the shutdown routine, the device seems to get into a bad
> > state. A similar bug also occurs with btmtksdio (using MT7921).
> >
> > This change properly runs the shutdown routine, which should be
> > complementary to setup. The reason it unsets the HCI_USER_CHANNEL flag
> > is that some drivers have complex operations in their shutdown routine
> > (including sending hci packets) and we need to support the normal data
> > path for them (including cmd_timeout + recovery mechanisms).
> >
> > Note for v2: I've gotten a chance to test this on more devices
> > and figure out why it wasn't working before in v1. I found two problems:
> > I had a signal pending (SIGTERM) that was messing things up in the
> > socket release function and the HCI_USER_CHANNEL flag was preventing
> > hci_sync from operating properly during shutdown on Intel chipsets
> > (which use the sync functions to send a reset command + other commands
> > sometimes).
> >
> > This was tested with hci_qca (QCA6174-A-3), btmtksdio (MT7921-SDIO)
> > and btusb (with AX200).
> >
> >
> > Changes in v2:
> > - Clear HCI_USER_CHANNEL flag at start of close and restore at end.
> > - Add comment explaning why we need to clear flag and run shutdown.
> >
> > net/bluetooth/hci_sync.c | 19 ++++++++++++++++---
> > 1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> > index 422f7c6911d9..f9591fcefb8d 100644
> > --- a/net/bluetooth/hci_sync.c
> > +++ b/net/bluetooth/hci_sync.c
> > @@ -4731,9 +4731,18 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> > {
> > bool auto_off;
> > int err = 0;
> > + bool was_userchannel;
> >
> > bt_dev_dbg(hdev, "");
> >
> > + /* Similar to how we first do setup and then set the exclusive access
> > + * bit for userspace, we must first unset userchannel and then clean up.
> > + * Otherwise, the kernel can't properly use the hci channel to clean up
> > + * the controller (some shutdown routines require sending additional
> > + * commands to the controller for example).
> > + */
> > + was_userchannel = hci_dev_test_and_clear_flag(hdev, HCI_USER_CHANNEL);
> > +
> > cancel_delayed_work(&hdev->power_off);
> > cancel_delayed_work(&hdev->ncmd_timer);
> > cancel_delayed_work(&hdev->le_scan_disable);
> > @@ -4747,7 +4756,6 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> > }
> >
> > if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) &&
> > - !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) &&
> > test_bit(HCI_UP, &hdev->flags)) {
> > /* Execute vendor specific shutdown routine */
> > if (hdev->shutdown)
>
> I guess the idea here is that shutdown can be run without the
> HCI_USER_CHANNEL flag since the hdev is closing we don't expect any
> traffic from socket/user channel? In that case I'd probably suggest
> having this on its own function e.g. hci_dev_shutdown which can have
> the logic of resetting the flag and restoring at the end. Also it is
> probably a good idea to have some test mimicking this behavior on
> userchan-tester so we do not accidentally break it.
Yup, that sounds reasonable. I'll look into userchan-tester before
sending up a v3.
>
> > @@ -4756,6 +4764,8 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> >
> > if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
> > cancel_delayed_work_sync(&hdev->cmd_timer);
> > + if (was_userchannel)
> > + hci_dev_set_flag(hdev, HCI_USER_CHANNEL);
> > return err;
> > }
> >
> > @@ -4795,7 +4805,7 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> > auto_off = hci_dev_test_and_clear_flag(hdev, HCI_AUTO_OFF);
> >
> > if (!auto_off && hdev->dev_type == HCI_PRIMARY &&
> > - !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) &&
> > + !was_userchannel &&
> > hci_dev_test_flag(hdev, HCI_MGMT))
> > __mgmt_power_off(hdev);
> >
> > @@ -4808,7 +4818,7 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> >
> > hci_sock_dev_event(hdev, HCI_DEV_DOWN);
> >
> > - if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) {
> > + if (!was_userchannel)
> > aosp_do_close(hdev);
> > msft_do_close(hdev);
> > }
> > @@ -4858,6 +4868,9 @@ int hci_dev_close_sync(struct hci_dev *hdev)
> > memset(hdev->dev_class, 0, sizeof(hdev->dev_class));
> > bacpy(&hdev->random_addr, BDADDR_ANY);
> >
> > + if (was_userchannel)
> > + hci_dev_set_flag(hdev, HCI_USER_CHANNEL);
> > +
> > hci_dev_put(hdev);
> > return err;
> > }
> > --
> > 2.37.3.998.g577e59143f-goog
> >
>
>
> --
> Luiz Augusto von Dentz
Powered by blists - more mailing lists