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

[Johan Hovold]

On Thu, Jan 18, 2024 at 10:30:50AM -0500, Luiz Augusto von Dentz wrote:
> On Thu, Jan 18, 2024 at 3:40 AM Johan Hovold <johan@xxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> > > > On Tue, Jan 09, 2024 at 05:54:01PM +0000, Matthias Kaehlcke wrote:

> > > > 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.

So in the kernel you would parse any address coming from firmware or
user space to try to determine if it's given in reverse order? I don't
see how this would work as presumably some of the least significant
bytes would occasionally match a valid OUI even if you were somehow able
to determine that.

> > 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.

Thanks for the pointer. I'm trying nudge some of the distro folks to
look into this.

> > 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.

Ah, ok. Then generating an address is perhaps not an option, but reading
one out from a file and setting it would still be useful for cases like
the X13s which do have an address assigned (e.g. accessible through
windows or written on the box the machine came in).

Johan