In the embodiment I've seen, it's a ARM M-class core with some special crypto hardware and certain registers that allow the use of crypto keys without software running on the core ever seeing the key. There's a communication channel to the rest of the system, which is completely OS-agnostic.

In Azure Sphere, Windows is nowhere in sight. The device runs a Linux Kernel.

Is this replacing the Cortex A5 used for the PSB? https://www.servethehome.com/amd-psb-vendor-locks-epyc-cpus-...

If Qualcomm is implementing it, I'm sure it will on a technical level. Linux is important to AMD and Intel, but Linux-running devices represent nearly all of Qualcomm's non-embedded SOC market.

Whether vendors can use it to restrict such things, I don't think anyone can say right now, but I would guess and hope not. The TPM does not.

If Qualcomm is implementing it then it should be easy enough to break. Qualcomm's secure enclave software for Android has had an absolutely abysmal security track record. Apple gets all the press precisely because it's such an achievement (well, that and Apple is more well known). Qualcomm hacks have come out like every 6 months for nearly a decade, and nobody cares anymore.

well apple's enclave is broken aswell. https://arstechnica.com/information-technology/2020/10/apple...

well at least it needs physical access.

FWIW, I meant Apple secure enclave hacks get all the attention because they're more of an achievement, at least in terms of published hacks being more rare. I tried to keep track of published Qualcomm breaks--which usually don't require physical access as they involve classic software bugs--several years ago but gave up because they were too numerous yet not as widely publicized. I had plenty of fodder by then, though I try to take mental note of new breaks that [briefly] appear on HN or elsewhere.

I was keeping track of hacks for marketing material related to a security startup I was working on. The competition would have principally been smartphone-based authentication apps, both Android and iPhone.

A curated list of public TEE resources for learning how to reverse-engineer and achieve trusted code execution on ARM devices (include all major ARM silicon vendor) https://github.com/enovella/TEE-reversing

Lol. Even Google had to put Titan M on its Snapdragon based Pixels.

I don't think so given how much share Linux has on Azure, it simply would not be a wise move.

Do the kids remember Microsoft's ghastly Palladium, from 2 decades ago?

>Known Elements of the Palladium System:

> The system purports to stop viruses by preventing the running of malicious programs. The system will store personal data within an encrypted folder.

>The system will depend on hardware that has either a digital signature or a tracking number.

> The system will filter spam. The system has a personal information sharing agent called "My Man."

> The system will incorporate Digital Rights Management technologies for media files of all types (music, documents, e-mail communications). Additionally, the system purports to transmit data within the computer via encrypted paths

https://epic.org/privacy/consumer/microsoft/palladium.html

Booting Linux is really a policy question, not technical.

Is it a policy question without Pluton? I.e. will this allow hardware vendors additional means to prevent me from installing Linux?

> will this allow hardware vendors additional means to prevent me from installing Linux?

No. Pluton serves as an on-chip secure enclave for encryption keys and the like. This is unrelated to installing operating systems.

Will the final purchaser of the computer chip, i.e., the consumer, have r/w access to the contents of the enclave?

EDIT: s/access/r\/w & to the contents of/

I don't know. I can't even speculate without knowing what you mean by "access to the enclave".

If you mean access as in being able to arbitrarily read and write keys or data to/from it, then no, you won't be able to access it that way. After all that's the whole point - even physical access to the hardware won't enable you to extract information (keys, etc.) from it.

This means any data or firmware stored on the chip by Microsoft or any OEM (e.g. firmware encryption keys or device signatures) won't be accessible to consumers.

TPMs define interfaces, though that allow programs to access its capabilities, so there are ways to interact with the hardware (and those are documented as well so you can write applications or operating systems that support it).

To get an idea what the interface looks like, you can check out the documentation of the Windows API: https://docs.microsoft.com/en-us/windows/win32/secprov/win32...

There's also a list of some TPM commands available on the same site: https://docs.microsoft.com/en-us/windows/win32/secprov/addbl...

Oh silly you, of course not.

Technically hardware vendors can already prevent this since years (secure boot without custom keys and only including Microsoft Windows keys).