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 12:35:19 +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



On 4/30/2024 6:37 PM, Johan Hovold wrote:
> On Tue, Apr 30, 2024 at 06:22:26PM +0530, Janaki Ramaiah Thota wrote:
>> On 4/30/2024 12:37 PM, Johan Hovold wrote:
>>> On Mon, Apr 29, 2024 at 01:31:53PM -0400, Luiz Augusto von Dentz wrote:
> 
>>>> Anyway the fact that firmware loading itself is programming a
>>>> potentially duplicated address already seems wrong enough to me,
>>>> either it shall leave it as 00... or set a valid address otherwise we
>>>> always risk missing yet another duplicate address being introduced and
>>>> then used over the air causing all sorts of problems for users.
>>>>
>>>> So to be clear, QCA firmware shall never attempt to flash anything
>>>> other than 00:00:00:00:00:00 if you don't have a valid and unique
>>>> identity address, so we can get rid of this table altogether.
>>>
>>
>> Yes agree with this point.
>> BD address should be treated as invalid if it is 00:00:00:00:00:00.
> 
> We all agree on that.
> 
>> NVM Tag 2: bd address is default BD address (other than 0), should be
>> configured as valid address and as its not unique address and it will
>> be same for all devices so mark it is configured but still allow
>> user-space to change the address.
> 
> 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.  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.

In our opinion this provides best Out of box experience.

> Johan

-Janaki Ram


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ