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.
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.
It's perfectly legal to sell hardware with telemetries, homecalling and vulnerabilities that are known to the vendor but not published AKA accidental backdoors.
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.
...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.
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())
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.
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.
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.
First, Intel is apparently collecting telemetry underneath the OS?
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?