linux-kernel - Re: [PATCH] Bluetooth: qca: fix device-address endianness

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABBYNZLV9o9hsYGVTGA7dPby-j1P_a35yNrDy4d9PMJq=TaRsQ@mail.gmail.com>
Date: Thu, 18 Jan 2024 10:30:50 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Johan Hovold <johan@...nel.org>
Cc: Matthias Kaehlcke <mka@...omium.org>, Johan Hovold <johan+linaro@...nel.org>, 
	Marcel Holtmann <marcel@...tmann.org>, Johan Hedberg <johan.hedberg@...il.com>, 
	Bjorn Andersson <quic_bjorande@...cinc.com>, Konrad Dybcio <konrad.dybcio@...aro.org>, 
	linux-bluetooth@...r.kernel.org, linux-arm-msm@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org, 
	Balakrishna Godavarthi <quic_bgodavar@...cinc.com>, Doug Anderson <dianders@...gle.com>, 
	Stephen Boyd <swboyd@...gle.com>
Subject: Re: [PATCH] Bluetooth: qca: fix device-address endianness

Hi Johan,

On Thu, Jan 18, 2024 at 3:40 AM Johan Hovold <johan@...nel.org> wrote:
>
> On Wed, Jan 17, 2024 at 05:49:07PM -0500, Luiz Augusto von Dentz wrote:
> > On Wed, Jan 10, 2024 at 3:12 AM Johan Hovold <johan@...nel.org> wrote:
> > > On Tue, Jan 09, 2024 at 05:54:01PM +0000, Matthias Kaehlcke wrote:
>
> > > > hciconfig
> > > > hci0:   Type: Primary  Bus: UART
> > > >         BD Address: 8C:FD:F0:40:15:DC  ACL MTU: 1024:8  SCO MTU: 240:8
> > > >         UP RUNNING
> > > >         RX bytes:1700 acl:0 sco:0 events:95 errors:0
> > > >         TX bytes:128949 acl:0 sco:0 commands:578 errors:0
> > >
> > > And any user space tool overriding the address would currently need to
> > > provide the address in reverse order on Qualcomm platforms like this
> > > one (e.g. if generating the address for privacy reasons).
> >
> > Perhaps we could attempt to resolve the address byteorder, in
> > userspace we use hwdb_get_company to resolve the company but since
> > this shall only really care about Qualcomm range(s) perhaps we can
> > hardcode them check in which order the address is, that said if the
> > device is configured with a Static Random Address then that would not
> > work, but that is only really possible for BLE only devices.
>
> It's not just Qualcomm ranges; The Lenovo ThinkPad X13s that I noticed
> this on has been assigned a Wistron OUI, for example.

Well we could still attempt to check if it has a valid OUI and then it
fail swap and check again.

> We're still hoping to learn how to retrieve this address (from the
> secure world firmware) so that we can set it directly from the driver,
> but for now it needs to be set using btmgmt (or the local-bd-address
> devicetree property).
>
> As was discussed here:
>
>         https://github.com/bluez/bluez/issues/107
>
> it would be useful to teach bluetoothd to (generate and) set an address
> for devices that lack (accessible) persistent storage. And any such
> generic tool would need to work using the standard interfaces and the
> address endianness that those interfaces expect.

Yep, patches are welcome in this regard, note that we do something like this:

https://github.com/bluez/bluez/blob/master/src/adapter.c#L9847

But the first thing it checks is if the controller supports BR/EDR, so
if you want to extend that we need at least the OUI portion to be able
to allocate a valid public address, we could perhaps attempt to fetch
the manufacturer somehow or use the controller manufacturer
(adapter->manufacturer) in case there is nothing else to use.

> And from skimming the Bluetooth spec, I was under the impression that
> random addresses applied also to non-BLE devices (e.g. requiring the two
> most-significants bits to be 1).

Not really, BR/EDR/classic addresses are always considered public
addresses, the HCI interface doesn't even have an address type to be
able to handle something like a random address or privacy for the same
reason.

> But to summarise, I don't really see any way around fixing the Qualcomm
> driver.
>
> Johan



-- 
Luiz Augusto von Dentz