Depends on your level of paranoia and the age of the CPU.
The ME has had many security vulnerabilities and probably more to come. For an appliance some old CPU might be good enough, but it does not get security updates. Some claim the ME might contain a NSA backdoor. That the ME can do networking certainly doesn't give confidence. The US government can order CPUs without ME, but nobody else can. Does not raise confidence either.
Please don't call it "paranoia": a whole lot of vulnerabilities have been found in CPUs together with plenty of undocumented functions that look just like backdoors.
On top of that, it is well known that governments research or buy 0-day hardware and software vulnerabilities and keep them secret to be used as weapons.
ME is just a fraction of the attack surface. When I read the title of the article I thought "trustworthy" was about mitigating hardware vulnerabilities.
Every intel cpu past 2008 contains a coprocessor which runs at a higher permissions level than the normal CPU and therefor the OS. Its primary function is DRM for video and theorized backdoor access for governments.
The short version is "It's complicated". Most ARM cores have a feature called TrustZone. Effectively, there's a set of system resources that are allocated to TrustZone and not accessible from the normal world. Various events can trigger the CPU to transition into executing code in this "Secure world", at which point the core stops running stuff from the normal world and instead starts running an entirely separate set of things. This can be used to do things like "hardware" key generation, DRM management, device state attestation and so on. Whether a specific platform makes use of TrustZone is largely up to the platform designers, but there's plenty of room to hide backdoors there if you were so inclined.
TrustZone is a CPU mode, hence it is not fully isolated from normal CPU operation. The CPU chooses to enter it and the current CPU state gets saved/restored. It contains the highest exception level, so it is able to access all memory. It does not usually have networking because that would invite complexity, but there is nothing to stop a vendor from putting a full network stack in there and assigning a network peripheral. Typically, it would rely on the main OS to send and receive packets.
Console and phone manufacturers have chased this dream for decades and each and every one has been hacked to run arbitrary code and applications that are supposed to ‘only run on trusted hardware’.
You can make it difficult but defeating an attacker who can touch the hardware is for all intents and purposes impossible.
edit I found that Microsoft did the smart thing like Sony did with the original PS3 and allowed people to run their own code (but not XBox games) on their consoles, removing a large incentive for people hacking the console.
That doesn’t automatically make the security watertight though.
"Never" is a strong word, but given that they're already previous generation devices and haven't been properly compromised yet, it wouldn't surprise me.
It's right there in the article : " In the general purpose Linux world, we use an intermediate bootloader called Shim to bridge from the Microsoft signing authority to a distribution one. "
So you need to trust Microsoft for the first keys :)
We do that for convenience, so you can boot Linux without having to hunt through firmware menus to reconfigure them. But every machine /should/ let the user enroll their own keys[1], so users are free to shift to a different signing authority.
[1] Every machine I've ever had access to has. If anyone has an x86 machine with a Windows 8 or later sticker that implements secure boot but doesn't let you modify the secure boot key database, I have a standing offer that I'll buy one myself and do what I can to rectify this. I just need a model number and some willingness on your part to chip in if it turns out you were wrong.
I have been trying to improve the usability of secure boot key management on Linux for the past year by writing some libraries from scratch and sbctl. I have even started writing full integration testing with tianocore/ovmf!
It should hopefully end up being an improvement on efitools and sbsigntools. Tried posting about this on HN but somehow it's a topic with little to no interest, strange world!
Most Surface Pro x86 devices do not let you enroll user keys through the firmware. In fact the original Surface Pro doesn't even have the UEFI MS key, so it can't even boot Shim. Following Surface devices do allow you to enroll the MS UEFI key through a firmware update (requires Windows), and starting from Surface Pro 3 iirc the UEFI MS key is builtin (but still no option to enroll your keys through the firmware).
However, they all do have the option to disable Secure Boot entirely (and you get a permanent red boot screen for the privilege).
“ Dan would eventually find out about the free kernels, even entire free operating systems, that had existed around the turn of the century. But not only were they illegal, like debuggers—you could not install one if you had one, without knowing your computer's root password. And neither the FBI nor Microsoft Support would tell you that.”
