linux-kernel - Re: [PATCH] Bluetooth: qca: generalise device address check

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: Thu, 2 May 2024 22:33:34 +0530
From: Janaki Ramaiah Thota <quic_janathot@...cinc.com>
To: Johan Hovold <johan@...nel.org>
CC: Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        Doug Anderson
	<dianders@...omium.org>,
        Johan Hovold <johan+linaro@...nel.org>,
        "Marcel
 Holtmann" <marcel@...tmann.org>,
        <linux-bluetooth@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>, <quic_mohamull@...cinc.com>,
        <quic_hbandi@...cinc.com>, <quic_anubhavg@...cinc.com>
Subject: Re: [PATCH] Bluetooth: qca: generalise device address check

Hi Johan,

On 5/2/2024 3:41 PM, Johan Hovold wrote:
> On Thu, May 02, 2024 at 12:35:19PM +0530, Janaki Ramaiah Thota wrote:
>> On 4/30/2024 6:37 PM, Johan Hovold wrote:
> 
>>> But here we disagree. A non-unique address is not a valid one as it will
>>> cause collisions if you have more than one such controller.
>>>
>>> I understand that this may be convenient/good enough for developers in
>>> some cases, but this can hurt end users that do not realise why things
>>> break.
>>>
>>> And a developer can always configure an address manually or patch the
>>> driver as needed for internal use.
>>>
>>> Are there any other reasons that makes you want to keep the option to
>>> configure the device address through NVM files? I'm assuming you're not
>>> relying on patching NVM files to provision device-specific addresses
>>> after installation on target?
> 
>> We prefer unique address to be flashed on OTP (persistent) memory of
>> BT-Chip, which is supported by almost all QC BT-chips.
> 
> Yes, that is certainly the best option for everyone.
> 
>> If someone is not able to do that/ does not prefer that, they still
>> have an option to flash unique address in firmware binary (NVM)file.
>> This does not require setting BD address from user space.
>>
>> Also until a developer flashes OTP/ keep unique BD-Address in NVM,
>> he should be able to run most of the use cases from Device, that's
>> why we want to make it as configured.
> 
> Ok, but a developer can still do this since they can patch the driver to
> disable the check temporarily or, alternatively, just update the
> devicetree with a valid unique address.
> 
>> In our opinion this provides best Out of box experience.
> 

If a developer has to patch a code/update device-tree, that is not
a "out of box" experience. By "out of box" we meant, things should
work without much changes required.

> You can also look into improving support in user space (e.g. bluez) for
> providing a valid unique address in a simple text-based configuration
> file.
> 

We don't think putting a must-have dependency in user space is the
right thing to do, especially when we own a code in kernel space.

> That would be useful for all Linux users and not require having access
> to Qualcomm specific tools to update the NVM configuration file (which
> could also be in a read-only file system, e.g. on Android).
> 

Having a non-unique valid address allows a developer to handle all
scenarios where he/she is dealing with DUT + commercial device and
in such case, default BD-Address from nvm file should also be okay.
Only when 2/more similar devices are in the mix, they need unique
address. In that case we are providing end developers with a NVM
utility(part of Qcom build Not open source tool)to change this
default BD-Address.

> Johan

-Janaki Ram