đŸ’Ÿ Archived View for nytpu.com â€ș gemlog â€ș 2022-08-04.gmi captured on 2023-03-20 at 17:55:11. Gemini links have been rewritten to link to archived content

View Raw

More Information

âŹ…ïž Previous capture (2023-01-29)

-=-=-=-=-=-=-

↩ go back to index

Thinking About ARM TrustZone

August 4, 2022

I've found I rarely have the motivation to write really long and in-depth posts recently, and yet I have a strong motivation to write medium-length posts such as this one. This is my gemlog so I don't know why I keep holding myself to writing standards instead of just writing what I feel like, so I'm at least going to try writing more stuff like this rather than just not writing anything as I've been doing.

⁂

For those who don't know, most modern ARM processors have a feature called TrustZone. It's sorta similar in concept to but not execution to crap such as Intel Management Engine (or more aptly, Intel SGX?) or AMD Secure Technology. Unlike Intel Malware Engine, the owner of the device theoretically has access to it to run what they want; it's essentially a second processor core that runs processes in the “secure world”, and it has full access to the hardware and currently running system. The secure world can take ownership of resources such as memory segments, DMA transfers, interrupts, and even external perephrial access. The other cores run in the “non-secure world” and do not have any direct access to resources owned by the secure world, they can only access said resources by getting them transferred via a secure world process.

I think it's a really nifty idea; ssh-agent and other key storage stuff could run their processes in the secure world, you could decrypt secure data in there, lots of potentially nice things. Especially if you had a microkernel instead of a monolithic kernel, you could have some kernel processes in the secure world and the rest in the untrusted world.

However, in its current state, it's bad in the same way Secure Boot is bad (it's generally a good idea but there's awful, awful vendor lock-in). AFAIK the only current use for it is locking it so only the vendor can access it and doing DRM, copy protection, cryptographic verification of boot payloads (without the user being able to change it, Ă  la Secure Boot), bullshit like that. While you can access the trusted world on ARM development kits, I don't know if you can access it on any current consumer hardware, even “open hardware”ᔃ stuff like the MNT Reform.

I'd say it's possibly even irreconcilably bad; as I personally believe Secure Boot is. Even if the ideas behind them are good, they're both so entrenched as anti-consumer functionality with literally no benefit to the user that the only way they could be made better is by entirely throwing them out and starting again from first principles.

[a]: thread on the the dubiousness of calling stuff OSHW when only the PCB is OSHW and the chips that actually do 99% of the functions aren't open

⁂

↩ go back to index

contact: alex [at] nytpu.com

backlinks

-- Copyright © 2022 nytpu - CC BY-SA 4.0