Hacker News Reader

Comment by R0b0t1 | Hacker News Reader

You can't. The post is still somewhat valuable, but should really not use "trustworthy."

Dealing in absolute terms does not help security. It depends entirely on your threat model.

If you consider NSA or similar agencies a problem then you are in a world of pain anyway and using an entry level guiding blog post is certainly not appropriate.

For everyone else, this puts already quite a big defense layer to your arsenal even if not unhackable in absolute terms.

I know. Thus I said:

>The post is still somewhat valuable, but should really not use "trustworthy."

The posted article is dealing in absolutes, not me.

Why can't you? The article explains how.

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.

What's ME? The article doesn't seem to mention this.

https://en.wikipedia.org/wiki/Intel_Management_Engine, AMD has something similar.

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.

It should be noted that AMD has an equivalent management engineZ

But ARM hasn't. Or have they added something to their server range of designs?

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.

Hmm, I have never seen Trustzone as comparable to ME.

Trustzone is a secure execution environment, mostly isolated from normal CPU operation. Wasn't it so that it cannot even access main memory???

ME is really more privileged than the CPU?

I have not heard about Trustzone doing networking. But ME can supposedly do even WLAN while the CPU is not running.

Disclaimer: I am not a hands-on expert at that level, more like an armchair pilot...

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.

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.

At this stage it's practically impossible. :(

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 :)

“ 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.”

Source: The Right to Read, a short story by RMS, 1997.

https://www.gnu.org/philosophy/right-to-read.en.html

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!

https://github.com/Foxboron/sbctl

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).

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.

Where are the hacks that let you run arbitrary code on an Xbox One running current firmware?

Do you think they will never exist?

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.

Reply on news.ycombinator.com