linux-kernel - Re: [PATCH] Bluetooth: vendor specific ISO data packet identification by handle

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]

Message-ID: <CAAa9mD2KCABHppF+7g8B75eJmPesUJWuFZm+XQedzN+BT+U81Q@mail.gmail.com>
Date: Thu, 23 May 2024 11:25:20 +0800
From: Ying Hsu <yinghsu@...omium.org>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: linux-bluetooth@...r.kernel.org, 
	chromeos-bluetooth-upstreaming@...omium.org, 
	Marcel Holtmann <marcel@...tmann.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Bluetooth: vendor specific ISO data packet identification
 by handle

Paul and Luiz, thanks for the suggestions.
I would like to use different names for hci_pkt_type and pkt_type for
clear layering. Will post another revision later today.


On Wed, May 22, 2024 at 10:11 PM Luiz Augusto von Dentz
<luiz.dentz@...il.com> wrote:
>
> Hi Ying,
>
> On Wed, May 22, 2024 at 7:11 AM Ying Hsu <yinghsu@...omium.org> wrote:
> >
> > When HCI raw sockets are opened, the Bluetooth kernel module doesn't
> > track CIS/BIS connections. User-space applications have to identify
> > ISO data by maintaining connection information and look up the mapping
> > for each ACL data packet received. Besides, btsnoop log catpured in
> > kernel would couldn't tell ISO data from ACL data in this case.
> >
> > By differentiating ISO data from ACL data earlier in btusb, we can
> > eliminate unnecessary lookups and improve btsnoop log clarity.
> > This patch enables vendor-specific differentiation between ISO and
> > ACL data packets.
> >
> > Signed-off-by: Ying Hsu <yinghsu@...omium.org>
> > ---
> > Tested LE unicast recording on a ChromeOS device with Intel AX211
> >
> >  drivers/bluetooth/btusb.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 79aefdb3324d..543961b6c671 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -889,6 +889,8 @@ struct btusb_data {
> >         int (*recv_acl)(struct hci_dev *hdev, struct sk_buff *skb);
> >         int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
> >
> > +       int (*is_iso_data_pkt)(struct sk_buff *skb);
>
> I'd had this sort of callback in hdev itself so the stack can consult
> the driver about packet types at any stage, see bellow.
>
> > +
> >         int (*setup_on_usb)(struct hci_dev *hdev);
> >
> >         int oob_wake_irq;   /* irq for out-of-band wake-on-bt */
> > @@ -1229,6 +1231,8 @@ static int btusb_recv_bulk(struct btusb_data *data, void *buffer, int count)
> >
> >                 if (!hci_skb_expect(skb)) {
> >                         /* Complete frame */
> > +                       if (data->is_iso_data_pkt && data->is_iso_data_pkt(skb))
> > +                               hci_skb_pkt_type(skb) = HCI_ISODATA_PKT;
>
> Id keep a single point in the stack doing the reclassification of the
> packets, which should probably be in hci_recv_frame, Id suggesting
> doing something like:
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index b3ee9ff17624..505ef0b58f8c 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -2941,6 +2941,14 @@ int hci_reset_dev(struct hci_dev *hdev)
>  }
>  EXPORT_SYMBOL(hci_reset_dev);
>
> +static u8 hci_pkt_type(struct hic_dev *dev, struct sk_buff *skb)
> +{
> +       if (hdev->pkt_type)
> +               return hdev->pkt_type(dev, skb);
> +
> +       return hci_skb_pkt_type(skb);
> +}
> +
>  /* Receive frame from HCI drivers */
>  int hci_recv_frame(struct hci_dev *hdev, struct sk_buff *skb)
>  {
> @@ -2950,6 +2958,10 @@ int hci_recv_frame(struct hci_dev *hdev, struct
> sk_buff *skb)
>                 return -ENXIO;
>         }
>
> +       /* Check if the driver agree with packet type classification */
> +       if (hci_skb_pkt_type(skb) != hci_pkt_type(skb))
> +               hci_skb_pkt_type(skb) = hci_pkt_type(skb);
> +
>         switch (hci_skb_pkt_type(skb)) {
>         case HCI_EVENT_PKT:
>                 break;
>
>
> >                         btusb_recv_acl(data, skb);
> >                         skb = NULL;
> >                 }
> > @@ -2539,6 +2543,13 @@ static int btusb_recv_bulk_intel(struct btusb_data *data, void *buffer,
> >         return btusb_recv_bulk(data, buffer, count);
> >  }
> >
> > +static int btusb_is_iso_data_pkt_intel(struct sk_buff *skb)
> > +{
> > +       __u16 handle = (__le16_to_cpu(hci_acl_hdr(skb)->handle) & 0xfff);
> > +
> > +       return (handle >= 0x900);
> > +}
> > +
> >  static int btusb_send_frame_intel(struct hci_dev *hdev, struct sk_buff *skb)
> >  {
> >         struct urb *urb;
> > @@ -4361,6 +4372,9 @@ static int btusb_probe(struct usb_interface *intf,
> >                 /* Override the rx handlers */
> >                 data->recv_event = btintel_recv_event;
> >                 data->recv_bulk = btusb_recv_bulk_intel;
> > +
> > +               /* Override for ISO data packet*/
> > +               data->is_iso_data_pkt = btusb_is_iso_data_pkt_intel;
> >         } else if (id->driver_info & BTUSB_REALTEK) {
> >                 /* Allocate extra space for Realtek device */
> >                 priv_size += sizeof(struct btrealtek_data);
> > --
> > 2.45.1.288.g0e0cd299f1-goog
> >
>
>
> --
> Luiz Augusto von Dentz