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]
Date: Wed, 17 Jan 2024 17:49:07 -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 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:
> > On Tue, Jan 09, 2024 at 06:12:26PM +0100, Johan Hovold wrote:
>
> > > That depends on in what way the current devices are broken.
> > >
> > > Any machines that correctly specify their address in little-endian order
> > > in the devicetree would no longer be configured using the wrong address.
> > > So no problem there (except requiring users to re-pair their gadgets).
> > >
> > > And tools like btgmt is broken on all of these Qualcomm machine in any
> > > case and would now start working as expected. So no problem there either
> > > (unless user space had adapted an inverted the addresses to btmgmt).
> > >
> > > So the first question is whether there actually is any boot firmware out
> > > there which passes the BD_ADDR in reverse order?
> >
> > Yes, (at least) the boot firmware for sc7180-trogdor devices.
> >
> > hexdump -C /proc/device-tree/soc\@0/geniqup\@8c0000/serial\@88c000/bluetooth/local-bd-address
> > 00000000  8c fd f0 40 15 dc
>
> Indeed, this should have been LE order.
>
> > 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.

> > > > I suggest adding a quirk like 'local-bd-address-msb-quirk' or
> > > > 'qcom,local-bd-address-msb-quirk' to make sure existing devices keep
> > > > working properly.
> > >
> > > I don't think that would work. If this is something that we really need
> > > to handle, then there's probably no way around introducing new
> > > compatible strings for boot firmware that isn't broken while maintaining
> > > the current broken behaviour with respect to 'local-bd-address' for some
> > > of the current ones.
> >
> > I think it should work for sc7180-trogdor. For these devices the device tree
> > is bundled with the kernel image and can be updated. That might not be true
> > for other devices though.
>
> Thanks for confirming.
>
> I'm still hoping we can get away with not having to add quirks to
> Bluetooth core for broken Qualcomm boot firmware. Let's see if anyone
> knows of a use case that makes that impossible to avoid.
>
> Johan



-- 
Luiz Augusto von Dentz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ