Intel embedded graphics contain embedded x86 CPU and operating system. Windows driver "riddled" with telemetry

[metablazingkin]

Summary

 

Security researcher Igor Bogdanov has reverse engineered the architecture of Intel's embedded graphics and has uncovered details about the silicon and software.

 

They revealed information about the graphics processor's internal x86 CPU, named the GuC. The GuC manages graphics scheduling, power management, and firmware verification.

The GuC itself runs a small, real-time operating system called μOS that manages the graphics core and communication to the main CPU.

 

They also analyzed the Windows driver, finding a way to enable debug information. The driver is apparently "riddled" with telemetry, although no specifics are given and it is unclear if, or how often this telemetry is sent to Intel.

 

Quotes

Quote

The GuC is a small embedded core that supports graphics sechduling, power managment and firmware attestation. It is implemented in an i486DX4 CPU (also called P24C and Minute IA), although it seems that since broadwell it has been extended to the Pentium (i586) ISA. It runs a small microkernel call μOS. The GuC μOS runs only kernel level tasks (even though μOS supports μApps). The firmware is written in C with not stdlib. In the GuC we can find supporting blocks: ROM memory, 8KB L1 on core cache, 64KB/128KB/256KB (Broadwell/Skylake/CannonLake) of SRAM memory which is used for code+data+cache and a 8KB stack. It also has power managment, DMA engine, etc’. Communication to the GuC is done through memory-mapped IO and bidirectional interrupts.

 ...

Why is the GuC interesting? Because I think it can communicate with the CSME, CPU and GPU and everything over the IOSF, and if it has bugs it can be used to gain very privileged access to the system and memory.

 ...

The GPU driver is riddled with telemetry, but I haven’t figured out yet how much of it is sent automatically to Intel, altough crashes are sent through OCA - Online Crash Analysis.

 

My thoughts

This revelation has big security implications, mirroring the discovery of the Intel Management Engine.

 

We've known that the GuC has existed for a while, but this is the first time we are seeing so much detail about it (like that it's a full x86 core)

 

While no known attacks exist yet, this graphics core and the operating system running on it, have a large target painted on their back.

It could potentially provide unrestricted access to the entire system if even small exploits are found (since it appears have direct access to the memory bus).

 

Debugging and telemetry in the driver are interesting from a privacy perspective. I don't think Intel is intentionally stealing people's data, but it seems like any crash logs you might upload may unintentionally leak private information.

The debugging information is likely very interesting to Linux developers, who might be able to use it to make improvements to the Linux open source driver.

 

Sources

https://igor-blue.github.io/2021/02/10/graphics-part1.html (The article itself)

https://www.kernel.org/doc/html/v4.10/gpu/i915.html#guc (An example of what we knew about the GuC previously)

[WhitetailAni]

So your Intel CPU has a CPU that runs an OS that tells Intel what the CPU (not the CPU CPU) is doing.

Great.

[jagdtigger]

Bog corporations never learn......

[kvuj]

Intel and garbage co processor implementation that lead to high security risks... Name a more iconic duo!

 

I doubt the GPU can ping some severs over on Linux considering the drivers are open source & they would be crucified if something similar got found. I also doubt your processor has direct access to ethernet ports. Though this is Intel we are talking about, they might just do that with some horrible marketing like "Next Level Gaming Latency".

 

Quote

It is implemented in an i486DX4 CPU (also called P24C and Minute IA), although it seems that since broadwell it has been extended to the Pentium (i586) ISA

Wait... what? Why would you pick a gigantic ISA with variable length instruction decoding for GPU use? Wouldn't that shred your performance?

[metablazingkin]

34 minutes ago, kvuj said:

Intel and garbage co processor implementation that lead to high security risks... Name a more iconic duo!

 

I doubt the GPU can ping some severs over on Linux considering the drivers are open source & they would be crucified if something similar got found. I also doubt your processor has direct access to ethernet ports. Though this is Intel we are talking about, they might just do that with some horrible marketing like "Next Level Gaming Latency".

 

Wait... what? Why would you pick a gigantic ISA with variable length instruction decoding for GPU use? Wouldn't that shred your performance?

Right, I was thinking the same thing. I would have thought they'd use a RISC chip for the embedded application. Maybe it was simpler to implement since they've already got the IP?

[Drama Lama]

I am not surprised

[atxcyclist]

Not going to call myself an AMD fanboy or anything, but... WTF Intel?

[CarlBar]

1 hour ago, metablazingkin said:

Right, I was thinking the same thing. I would have thought they'd use a RISC chip for the embedded application. Maybe it was simpler to implement since they've already got the IP?

 

Ad plenty of experiance with it. It's simple, it works, and they know what they're doing with it. Makes perfect sense to me.

[Drama Lama]

52 minutes ago, atxcyclist said:

Not going to call myself an AMD fanboy or anything, but... WTF Intel?

I'm pretty sure AMD has some less stinky bullsh*t in their silicon

[porina]

4 hours ago, kvuj said:

Wait... what? Why would you pick a gigantic ISA with variable length instruction decoding for GPU use? Wouldn't that shred your performance?

It doesn't do work. It is only there for management related features, and I'm sure they would have picked something with "enough" performance for that. The 486 I know from my own 1st PC in 1993. I wouldn't be surprised if there are modern microcontrollers who could do more work than it now. 

 

3 hours ago, metablazingkin said:

Maybe it was simpler to implement since they've already got the IP?

This.

 

 

I guess many here don't pay attention to Intel software e.g. if they're AMD/nvidia only in recent times. Some Intel software offerings have you click on agreements when you install. Nothing new? The first one is the licence which is normal. Everyone clicks that without reading. There's sometimes a 2nd one. If you click that without reading, congratulations, you just agreed to share data with Intel. You can decline that and progress the install, but it does mean you had to read enough to know to move your mouse over to the no button and not just spam ok. BTW if you have accidentally installed it, you can just uninstall it from Control Panel. I think it is called something like Intel Consumer Improvement Program or something like that. I'm not sure what it is offered with, I think it might come with DSA or XTU, but I don't recall seeing it in the chipset or GPU driver packages for example.

[Taf the Ghost]

Intel is amazingly committed to putting a x86 core everywhere, lol. If you don't know, this is the most classic of Intel moves. Technically, this was the same approach that Larrabee took as well back in the 2000s.

 

The one thing is that microcontrollers are always using telemetry. CPU or GPU temperature being the most notable ones. What would actually matter would be what it stores and what can be extracted. While there is some hilariously strange things you can do to a system with different access types, it'll be interesting to see it play out. Do realize most Intel "Commercial" type products are designed to be managed remotely, as a result, per-unit security is managed differently. Obviously, the worry is what sits inside Desktop iGPUs.

[Tristerin]

Heres some chiplet on your chiplet

[kvuj]

3 hours ago, gabrielcarvfer said:

People get mad when they discover hidden x86 processors, but not with hidden ARM processors are just being unfair...

...or it's because Intel has a horrible security record and their CPUs are used by ~80% of the desktop market.

 

From their ME to their AMT scoring a CVSS 9.8 / 10 to Thunderspy/Thunderclap (thunderbolt vulnerability), as soon as I learn about another small Intel CPU, I get dubious.

[StDragon]

"Telemetry computing". You know, at some point I wouldn't be surprised if dedicated telemetry chiplets or cores are created and the cost subsidized by the likes of Microsoft, Apple, Google, and Facebook to spy on your usage.

 

 Though most likely a more insidious marketing campaign will have you pay for it as a form of "productivity enhancements".

[steelo]

13 hours ago, metablazingkin said:

Summary

 

Security researcher Igor Bogdanov has reverse engineered the architecture of Intel's embedded graphics and has uncovered details about the silicon and software.

 

They revealed information about the graphics processor's internal x86 CPU, named the GuC. The GuC manages graphics scheduling, power management, and firmware verification.

The GuC itself runs a small, real-time operating system called μOS that manages the graphics core and communication to the main CPU.

 

They also analyzed the Windows driver, finding a way to enable debug information. The driver is apparently "riddled" with telemetry, although no specifics are given and it is unclear if, or how often this telemetry is sent to Intel.

 

Quotes

 

My thoughts

This revelation has big security implications, mirroring the discovery of the Intel Management Engine.

 

We've known that the GuC has existed for a while, but this is the first time we are seeing so much detail about it (like that it's a full x86 core)

 

While no known attacks exist yet, this graphics core and the operating system running on it, have a large target painted on their back.

It could potentially provide unrestricted access to the entire system if even small exploits are found (since it appears have direct access to the memory bus).

 

Debugging and telemetry in the driver are interesting from a privacy perspective. I don't think Intel is intentionally stealing people's data, but it seems like any crash logs you might upload may unintentionally leak private information.

The debugging information is likely very interesting to Linux developers, who might be able to use it to make improvements to the Linux open source driver.

 

Sources

https://igor-blue.github.io/2021/02/10/graphics-part1.html (The article itself)

https://www.kernel.org/doc/html/v4.10/gpu/i915.html#guc (An example of what we knew about the GuC previously)

Yeah. No thanks. Another reason to steer clear of Intel. 

[Fnige]

16 hours ago, atxcyclist said:

Not going to call myself an AMD fanboy or anything, but... WTF Intel?

Your called atxcyclist, so you already fine there

[Video Beagle]

On 2/10/2021 at 8:58 PM, metablazingkin said:

They also analyzed the Windows driver, finding a way to enable debug information. The driver is apparently "riddled" with telemetry,

isn't this normal? to have a debug mode that spits out logs which is what telemetry is?

[Guest]

On 2/11/2021 at 11:47 PM, Taf the Ghost said:

Intel is amazingly committed to putting a x86 core everywhere, lol. If you don't know, this is the most classic of Intel moves. Technically, this was the same approach that Larrabee took as well back in the 2000s.

 

Putting more core everywhere but in their CPUs 

[Sauron]

On 2/11/2021 at 4:58 AM, metablazingkin said:

it is unclear if, or how often this telemetry is sent to Intel.

Telemetry with no calling home isn't much of a security issue so that would matter quite a bit. If it's just a bunch of statistics it uses to improve its scheduling then it's just fine.