Intel Clarifies HECI Usage For Arc Graphics' GSC

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

[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?

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

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

[arun54321]

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

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

[stormcrow]

I wouldn't even jump through that hoop to hypothetically justify a possible convoluted rube goldberg design.
I've been designing in system update-able FW for decades. It's really simple.
Send a FW image to the end device MCU/CPU. It receives it from directly from wherever treating it as presumed corrupted / invalid by default.
When the transfer completes it checks the hash / signature on the received BLOB and throws it away if it isn't valid, and proceeds to do the update
it if is.

I fail to see how some "man in the middle" third party based signing / verification thing is fundamentally going to make that any better in any relevant way.
Anyone has physical access to the PCIE slot's JTAG/SMBUS lines so one can send data to those on any platform that connects them to some other
CPU/MCU so it isn't as if somehow there's a secure path between the ME and the GSP, it's all via the PCIE slot signal lines.

It isn't as if they're going to use the TPM or something to let people redefine which FW signing keys they want their GPU GSC to accept so they can have
open source user customizable user-signed GSC FW. I think the use case is either the FW is signed by Intel in a way the GSC is hard coded to accept, or it isn't, and nothing else matters but pushing bits from the FW blob on disc to the card's CPU, done.

It smells like either incompetence or malevolence or some combination of both.

Relying on SMBUS / JTAG or whatever for ANYTHING post consumer-sale seems vaguely incompetent anyway; you've got a PCIE slot right there; use the PCIE bus for all I/O. At best the SMBUS / JTAG sideband signals are going to be less well supported / less portable and more of a headache to deal with in
heterogeneous end user systems than straight PCIE connectivity.

This is already after the 35W A750/A770 idle power oversight / incompetent design fiasco that their best supported "workaround" for is for users to go into their BIOS settings and change their PCIE ASPM power management state settings to non-default values, except (a) the large majority of BIOSs don't give the user menu control over those settings, and (b) the large majority of users are going to be too ignorant / unwilling / unable to even do that level of BIOS settings change even if that's what Intel support
commends to them. Yay very green and eco friendly, Intel, power wasting by default with maybe no driver level fix and maybe no other practical one possible
for some. That and the fact that so far it doesn't even seem to help the A770 from having a 4x too large Idle power consumption even when you do that.

Or the whole "you really need REBAR enabled for these GPUs to work well" but there again even on many otherwise suitable systems that work with fine performance on NVIDIA/AMD GPUs Intel GPUs lag without it and lots of people (apparently me included) have BIOSes that don't properly enable it even in suitable motherboards / systems and no OS / driver / architecture / SW level fix / workaround.

I didn't say I agree with the decision. I just said I understand why their engineer did it that way despite your explanation.

[torsionbar28]

Slow down everyone! This may not be Intel being malicious and trying to push their own processors/MBs with ME. It could just be that the person who designed the firmware update was familiar with ME and how to do firmware updates through that and never considered that not everything has ME. So, not malice, just basic incompetence.

Was thinking the same. At these companies, it is encouraged for engineering to "eat their own dog food" so to speak. Meaning, to leverage intel-developed software, hardware, tooling, etc. into new designs. Likely an engineer saw that he could accomplish the firmware update using an existing intel-developed thing (ME) and so that was the "obvious" path forward.

[nyanmisaka]

There is no explicit ME requirement to update the firmware according to the intel Arc GPU Q&A.

https://www.intel.com/content/www/us/en/support/articles/000089929/graphics/intel-arc-dedicated-graphics-family.html

[pong]

I wouldn't even jump through that hoop to hypothetically justify a possible convoluted rube goldberg design.
I've been designing in system update-able FW for decades. It's really simple.
Send a FW image to the end device MCU/CPU. It receives it from directly from wherever treating it as presumed corrupted / invalid by default.
When the transfer completes it checks the hash / signature on the received BLOB and throws it away if it isn't valid, and proceeds to do the update
it if is.

I fail to see how some "man in the middle" third party based signing / verification thing is fundamentally going to make that any better in any relevant way.
Anyone has physical access to the PCIE slot's JTAG/SMBUS lines so one can send data to those on any platform that connects them to some other
CPU/MCU so it isn't as if somehow there's a secure path between the ME and the GSP, it's all via the PCIE slot signal lines.

It isn't as if they're going to use the TPM or something to let people redefine which FW signing keys they want their GPU GSC to accept so they can have
open source user customizable user-signed GSC FW. I think the use case is either the FW is signed by Intel in a way the GSC is hard coded to accept, or it isn't, and nothing else matters but pushing bits from the FW blob on disc to the card's CPU, done.

It smells like either incompetence or malevolence or some combination of both.

Relying on SMBUS / JTAG or whatever for ANYTHING post consumer-sale seems vaguely incompetent anyway; you've got a PCIE slot right there; use the PCIE bus for all I/O. At best the SMBUS / JTAG sideband signals are going to be less well supported / less portable and more of a headache to deal with in
heterogeneous end user systems than straight PCIE connectivity.

This is already after the 35W A750/A770 idle power oversight / incompetent design fiasco that their best supported "workaround" for is for users to go into their BIOS settings and change their PCIE ASPM power management state settings to non-default values, except (a) the large majority of BIOSs don't give the user menu control over those settings, and (b) the large majority of users are going to be too ignorant / unwilling / unable to even do that level of BIOS settings change even if that's what Intel support
commends to them. Yay very green and eco friendly, Intel, power wasting by default with maybe no driver level fix and maybe no other practical one possible
for some. That and the fact that so far it doesn't even seem to help the A770 from having a 4x too large Idle power consumption even when you do that.

Or the whole "you really need REBAR enabled for these GPUs to work well" but there again even on many otherwise suitable systems that work with fine performance on NVIDIA/AMD GPUs Intel GPUs lag without it and lots of people (apparently me included) have BIOSes that don't properly enable it even in suitable motherboards / systems and no OS / driver / architecture / SW level fix / workaround.

I try not to jump to conclusions if I can manage it. My guess is that ME is just needed for certain firmware signing verification and the same functionality exists in AMD's equivilent PSP. Whoever wrote the Linux program may have overlooked this vector much like AMD often overlooks testing on Linux & BSD systems in general. Myopic corporate focus on market shares can have knock-on effects like this.

Now, that said it does mean that systems that try to kill most ME functionality may not be able to update ARC graphics card firmwares, so System 76 computers, for example, will be out.