zlacker

> In the end, x86 systems didn't become any more locked down.

And non-x86 systems? Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows? It feels careless to only care about x86, especially as other platforms proliferate.

In any case, lockdown is not the only threat that Trusted Computing presents. Remote attestation itself is dangerous. If we remove our x86 blinkers and look at the mobile world, we see it's already happening, with countless apps, including ones important to modern day life such as banking, refusing to run on rooted phones.

You may say, "Oh, I will use my x86 desktop system at home for Free Computing, and allow phones, consoles, tablets, surface devices, etc etc, to become locked down." Like the old free speech zones, this is a toothless freedom, tamed and neutered. The user-empowering Free Software you will write will have no users - they will be on locked devices.

>>jevote+(OP)
While that's true, with regard to some Surface devices, as I understand it, ARM systems have only become more open and interoperable over the past few years; although this holds true a lot more for the server side than desktop side.

The main issue these days is driver support. The PC platform was an anomaly in backwards compatibility, at least historically. I'm not arguing that it's going to be easy for FOSS. It's going to be an uphill battle, regardless of how locked down they are (and I'm just arguing that they won't be that locked down—see the recent M1 Macs for an example; Apple could easily have locked down those systems in exactly the same manner as iOS/iPadOS devices, but chose not to).

>>jevote+(OP)
Your ARM smartphone and/or IOT device don't support UEFI or secureboot, yet they were still locked down and you couldn't flash third party OSes. The problem is locked bootloaders, not UEFI or secureboot. Fearmongering over a largely non-problematic implementation (secureboot explicitly allows you to load your own keys) is exactly OP's point.

>>jevote+(OP)
> Wasn't there a line of MS Surface devices where secure boot could not be disabled, and users were stuck with Windows?

All Windows RT devices (32-bit Arm desktop Windows). Not only Secure Boot was locked down there, but apps had to be signed by Microsoft.

64-bit Windows on Arm adopts the security policy of x86_64 Windows, which means that you can turn off Secure Boot on production hardware. (and run your regular apps too)

>>messe+J
For arm: anything that runs Windows on Arm64 uses UEFI + ACPI, making stuff easier on that front.

Linux drivers for Qualcomm SoCs don't have extensive ACPI bindings at this point in time though, making the use of a separate devicetree necessary for full functionality. This will be mostly ironed out with time I suppose.

>>gruez+V
This sounds very much like "there are many ways to lock out users, why are you complaining about this specific method, when other platforms used a different one?"

>>messe+J
It's just really sad that Apple doesn't help us with drivers for their hardware, I highly doubt the majority would switch anyways, and assisting with info could be done with less effort if people are already doing reverse engineering work.

>>lillec+q2
I suspect it's a mix of legal difficulties in releasing the documentation, and a lack of incentive to write it in the first place.

The ideal scenario would be Apple pushing their hardware in the server space; that might create an internal incentive for apple to get Linux running decently (or at the very least make Darwin a new competitor in the datacenter).

>>jevote+o2
No it’s more like “why complain about a method that isn’t being used to lock down devices instead ones that are actually being used for that purpose”

>>jevote+o2
We should be complaining when it happens, not that any of these methods exist - they're super useful to have in many applications, eg. access control door locks, keeping PKI HSMs locked down, etc.

>>my123+H1
Didn't Linux developers say that Qualcomm's ACPI tables are a horrific Windows-specific mess that has close to zero standard PNP* things?

>>lillec+q2
The supported method is virtualization.

>>floatb+0R
> Windows-specific mess that has close to zero standard PNP* things

Those are hardware dependent platform devices. Qualcomm didn’t have another option. (Nor do other manufacturers really)

On x86, a virtual PCIe bus abstraction is heavily used, which is not the case for those SoCs.

(And well, if Linux wants to boycott full support of their SoCs, their choice. They just can’t blame Qualcomm anymore at that point.)

Another thing of note is the use of a PEP (power management plug-in) in the OS instead of having power management done in AML. The ACPI spec allows a manufacturer to do this. It isn’t used only by Qualcomm, but is totally unsupported on Linux today.

>>my123+lx1
Manufacturers have the option of producing standards-compliant goddamn hardware! Say for PCIe, even if it's a buggy and quirky implementation but it does support ECAM, you can still expose a PNP0A08 and deal with quirks in firmware (hello Socionext/Marvell/NXP).

> PEP (power management plug-in) in the OS […] ACPI spec allows a manufacturer to do this

Doing management in AML is almost the whole point of ACPI. Microsoft pushing this PEP thing into the ACPI spec is bad. This is the "letter" of ACPI now, unfortunately, but it's very much against the original "spirit" of ACPI :/

>>floatb+2C1
> Manufacturers have the option of producing standards-compliant goddamn hardware

For PCIe indeed, but that’s not when the issues are present the most. There’s no standard register interface for integrated GPUs, modems…

> but it's very much against the original "spirit" of ACPI

Yup, it’s what Device Tree does too however, shifting this to the OS.

Another downside is trying to have a good driver-less boot scenario when PEPs are used, for the system to be able to go far enough until drivers can be installed. (N/A to Linux which is hostile to not in-tree drivers, but very much a concern on Windows)