Intel Clarifies HECI Usage For Arc Graphics' GSC

[Viki Ai]

Wow! I came this >< close to buying an ARC-based system last week. Malice or incompetence, I don't want either in my systems any more than is absolutely unavoidable (something that gets harder every year anyway). My 10yo CPU and its 5yo GPU will have to chug on a bit longer, I guess.

[arun54321]

So we cannot update intel gpu firmware on amd cpus and motherboard?

[pong]

I'd be interested to find out if the SMBUS(?) based GSC FW mechanism is just using the ME path as a pure "transport" for transparently moving bits to the SMBUS/I2C/whatever port on the card from the main CPU or if they are indeed doing some non trivial protocol / encryption / whatever interaction "in the middle" of the main CPU and the GSC.

If they're really relying in a significant way on the ME/whatever chipset being anything other than a glorified SMBUS controller peripheral to the main CPU for this use case then it may be harder to get portable workarounds implemented either by
Intel engineering or by open source ports of the basic workflow if there are any "black box" opaque functions standing between
the FW update file BLOB bits as downloaded from the firmware repository and what bits get shoveled into the SMBUS port
on the device.

Previously some reference was made to /dev/mei* on the github repo so I assume that's one of the standard driver interfaces for LINUX to the ME sybsystem; I don't know if there's any useful documentation / open source driver information behind that.

And more relevantly for the AMD motherboard / chipset case, I don't know how the SMBUS / JTAG / whatever sideband lines that connect to the PCIE slot signals are driven at the X570 / X470 / whatever chipset level and how that's exposed to LINUX /dev/whatever as a SMBUS controller and how well documented / standard that is.

On one of my boxes I see:
lspci:
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller
Flags: 66MHz, medium devsel, IOMMU group 13
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4, sp5100_tco

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
Subsystem: ASUSTeK Computer Inc. FCH LPC Bridge
Flags: bus master, 66MHz, medium devsel, latency 0, IOMMU group 13

I don't even know if that's relevant or how portable the device interface is across different AMD platforms to say nothing
of POWER or whatever else.

Is it even standard SMBUS they're using as a transport with no significant added layers or did they coopt the signals into some horrible intel specific over-arching protocol stack on their motherboard chipset / PCIE designs when intel peripheral boards are used?

If the SMBUS FW UPD mechanism is just well documented, open specification, portable conceptually across platforms,
I wouldn't even be that angry (disappointed, yes, but not worse anyway) if Intel didn't support / implement others,
hell, I'd maybe write the code port for my X570 chipset myself given all the inputs / information if it is a straight simple
functional port to a different SMBUS controller API/device driver.

But if it's not even reasonably open / possible to do that ....

[Developer12]

Maybe someone will just built an emulator to run the ME-Software in a VM? Could backfire for intel, as this would open access to way more pentesting of ME-Software.

Not possible. A VM wouldn't have the needed hardware interfaces (the ME lives in the Platform Controller Hub, or at least used to), nor would it have the needed encryption/decryption keys stored in the ME.

[Developer12]

Wow intel, Fuck You.

With how buggy your cards and their drivers are at this point, I would really expect to have to update the drivers at least once. Locking that functionality to an intel cpu and motherboard? You're damning all your customers with AMD cpus to a subpar experience.

Perhaps all intel ARC benchmarks should be performed on AMD systems from now on?

That's in addition to further cementing reliance on the Management Engine, your skeevey foothold on the system and way to push unwanted "value add" like Digital Rights Management.

I will never willingly buy another intel product so long as I live.

PS: Oh, and anyone who *does* have an intel CPU: How many generations of ME back do you think they support? Will support?

[cj.wijtmans]

ME probably making sure theres spyware in your gpu so they can look at your monitor, what ME was designed for in the first place.

[timofonic]

RIP Arc.

[Nille]

Thank you Intel, now i can remove your cards again from the decision list.

[frackeverything]

Just Shintel things.

[yump]

Externally, Intel likes to pretend "intel" is synonymous with x86. Sometimes, employees and former employees carry this risible habit onto mailing lists.

Maybe internally they're high on their own supply and simply forgot that using the Intel ME for this would be problematic?