Security features of the Intel/Windows platform secure boot process | Hacker News Reader

Security features of the Intel/Windows platform secure boot process

igor-blue.github.io

95 pointsingve25 comments

Two bits surprised me.

First, Intel is apparently collecting telemetry underneath the OS?

   "The ITH can trace different internal hardware component (VIA - Visualization of Internal Signals, ODLA - On-chip logic analyzer, SoCHAP - SOC performance counters, IPT - Intel Process Trace, AET - Intel Architecture Trace), and external component like CSME, the UEFI firmware, and you can even connect it to ETW. *This telemetry eventually finds its way to Intel in various methods*."

The second is the nested complexity. The sheer quantity of stuff running before the bootloader is staggering. How is it possible to secure these nested trees of computers-in-computers?

It's not. In fact, look up what micro code is. Computers have been intentionally compromised for years in order to "catch the bad guys". Open source hardware that is subjected to intense security reviews is the way out of state sponsored hardware backdoors.

> this telemetry eventually finds its way to Intel in various methods

Wait what? How does that work, and how is that legal?

I guess via Intel ME drivers installed in Windows.

...Why rely on the installed OS? The ME already has networking capability. Further, most intel firmware seems to have it's own update channel. It probably uses the same mechanism.

From what I've seen, ME updates are bundled with UEFI updates.

Intel ME drivers are only to allow access from the local machine. Normally, localhost access would go through loopback, but ME can communicate only via the ethernet or wifi network adapter.

To access ME on other computers, you don't need any drivers.

> how is that legal?

It's perfectly legal to sell hardware with telemetries, homecalling and vulnerabilities that are known to the vendor but not published AKA accidental backdoors.

How? Money.

Given how malware has been demonstrated that infiltrates the Intel ME firmware, reads main memory and covertly exfiltrates data (through introducing packet jitter), I think it is safe to assume that Intel has the same abilities.

https://fahrplan.events.ccc.de/congress/2013/Fahrplan/events...

> The sheer quantity of stuff running before the bootloader is staggering. How is it possible to secure these nested trees of computers-in-computers?

Complexity and absence of peer review are the main enemies of security.

That stuff is incredibly complex and mostly closed.

> How is it possible to secure these nested trees of computers-in-computers?

https://github.com/corna/me_cleaner

Or, buy hardware from vendors who neutralize ME according to the link.

One idea of a "secure boot" would be to not have anything, save for what is necessary for hardware initialisation, outisde the user's control running before the bootloader. IMO, telemetry is a security breach. The whole notion of "secure boot" has nothing to do with "user security" (although it can be marketed that way). It has to do with companies having unfettered control over a hardware product after it has been sold. The companies seek to secure the ultimate control over the computer from anyone else, including the user. Many people seem to agree that software written by hardware companies is, generally, not relatively high quality.

> There is an undocumented feature in the kernel used by Graphics/DirectX to allow sharing the kernel's virtual memory address space with the graphics card (Device-TLB, ExShareAddressSpaceWithDevice())

Sounds like a promising attack vector

Huh nice article. This is my second time reading about something like this that mentions the PMC. I recall when I first heard about it, I tried to search the web for any documentation or information hackers had found. I found absolutely nothing related to x86.

Anyway I’ve since given up trying to understand the modern x86 PC platform in any detail, but it always fascinates me all the crap involved.

My understanding is that a fresh Win10 install on modern hardware is actually always running in a hypervisor. So called "core isolation".

Is that correct? I can't find any good article on this, only vague references.

I have a similar question. Some people say it's the default, but I have never seen it enabled by default, no matter how recent the hardware or the build number. I wonder under which conditions exactly it is enabled, if any.

If Hyper-V, Windows Defender Application Guard (or a couple other Defender features -- credential guard?) or WSL are enabled, Windows starts running under a hypervisor. By default it shouldn't be, unless your OEM or corporate IT has turned one of those features on.

How would I turn all that virtualisation off for more performance or is it embedded into the kernel nowadays?

Disable virtualization in the BIOS/UEFI before installing. As for a performance hit, virtualization in the silicon (through Intel VT-x or AMD-x) has almost none. Especially compared to what came before it where a VM had to essentially JIT the virtualized code.

Ah, interesting. So this way I will not end up running the same virtualisation in software mode?

Yeah, Hyper-V is just hardware virtualisation, it can't run in "emulation" mode.

This seems very thorough. Was this funded by Microsoft?

FYI, there is a tiny typo in the first paragraph: there -> they

Thanks, fixed it

that's a lot of engineering effort, damn.

Could this be a conspiracy in restraint of trade masquerading as security?

Reply on news.ycombinator.com