linux-kernel - Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

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]

Message-ID: <20211004111518.0765650c@localhost>
Date:   Mon, 04 Oct 2021 11:15:25 +0000
From:   Orlando Chamberlain <redecorating@...tonmail.com>
To:     Marcel Holtmann <marcel@...tmann.org>
Cc:     danielwinkler@...gle.com, Johan Hedberg <johan.hedberg@...el.com>,
        linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
        regressions@...ts.linux.dev, sonnysasaka@...omium.org
Subject: Re: [PATCHv2] Bluetooth: quirk disabling LE Read Transmit Power

On Fri, 01 Oct 2021 23:28:03 +1000
"Orlando Chamberlain" <redecorating@...tonmail.com> wrote:
> On Fri, 01 Oct 2021 19:35:16 +1000
> "Marcel Holtmann" <marcel@...tmann.org> wrote:
> 
> > I would really prefer to do that via the ACPI table matching in
> > hci_bcm.c and not via some magic chip id check.
> 
> Initially I thought we may be able to do this based off BCM2E7C (which
> is in the DSDT table which I'll attach), however it seems like many
> Macs also have that (i.e. MacBookPro14,1, MacBookAir8,1, MacBook9,1),
> so unless all these don't support LE Read Transmit Power, (which
> would be hard to determine), I don't know if BCM2E7C can be used to
> quirk it.

I think there aren't any Macs that support LE Read Transmit Power.

I checked the Bluetooth spec here
https://www.bluetooth.com/specifications/specs/core-specification-5-1/
and it seems like 5.1 is the first version that mentions LE Read
Transmit Power. It says 5.1 was adopted on 21 Jan 2019.

As far as I know, all of the models released after that date that have
ever had working Bluetooth were affected, while unaffected models were
released before that date (and thus shouldn't support LE Read Transmit
Power? This is at least true for the MacBookPro15,1, a 2018 model that
doesn't support the command).

I think this means that no Apple computer released so far supports the
command, so disabling LE Read Transmit Power for all Apple controllers
based off "apple-uart-blth" (probably a better choice than "BCM2E7C")
won't affect any controllers that actually support it.

Device (BLTH)
{
    Name (_HID, EisaId ("BCM2E7C"))  // _HID: Hardware ID
    Name (_CID, "apple-uart-blth")  // _CID: Compatible ID
    Name (_UID, One)  // _UID: Unique ID
    Name (_ADR, Zero)  // _ADR: Address

As to future Apple computers, they seem to no longer be using UART and
instead have a second Broadcom PCI device (the first being for WiFi)
that is for Bluetooth. 3 Intel Macs Models have this second device
(MacBookPro15,4, MacBookPro16,3 and MacBookAir9,1), and so do the M1
ones.

I can't say that they won't move back to UART at some point and then
support LE Read Transmit Power, but if they do, I don't think they
would move back to x86_64, so only having this quirk activated when
compiling for x86_64 might be an option if that's an issue.

> I'll try to see if I can find something else in the ACPI tables that
> can be used as a quirk. (I'll see if I can get the table of a similar
> model that wasn't affected and compare the BLTH sections)

The BLTH sections were the same for affected and unaffected macs.

Would disabling LE Read Transmit Power if the controller is
"apple-uart-blth" work for you?
--