Intel Clarifies HECI Usage For Arc Graphics' GSC

[archkde]

Apart from the lock-in aspect (which is obviously not good), I find it surprising there is updatable firmware at all. AFAIK, other GPUs (including Intel iGPUs) have their firmware loaded at runtime.

[nyanmisaka]

gsc-windows.png

GSC firmware interface is available on Windows on my AMD server. But I don't know if it works.

[stormcrow]

gsc-windows.png

GSC firmware interface is available on Windows on my AMD server. But I don't know if it works.

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.

Edit to add: It's almost a guarantee that if these cards don't actually require that kind of thing to update their firmware (ME or an equivalent security processor) then it won't be all that long before hackers figure it out and are able to compromise these cards with malicious firmware.

[milkylainen]

It's like they have a badwill account and are itching to overfill it.

[willmore]

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.

[pong]

That's absolutely an atrocious limitation / design decision.

If they designed it so you can't update the firmware other than via the SMBUS-like pins over the PCIE slot but could not do so over the PCIE lane traffic I find it very odd and likely problematic if they didn't know that (a) all platforms having PCIE slots had such SMBUS signals implemented and (b) all platforms had a suitable way to send update data to the peripheral card via that mechanism that would be equally well supported by the Intel tooling / drivers / updaters etc. Otherwise why wouldn't they just make it so the updates were sent to PCIE attached peripheral registers and have a much more simple / unified / portable implementation?

If they do intend to support all platforms but for the moment only the Intel chipset motherboards are supported by the OSS utility then the least they could do is fully document the necessary SMBUS or whatever exchange protocol and FW update data flow needed to send the FW image blobs through whatever the motherboard's plumbing may be to get it to the SMBUS pins on the right PCIE slot and be accepted by the GPU if someone else wanted to make an open source FW updater for other kinds of motherboards / platforms besides the one the intel utility presently works with -- that and commit publish the FW blobs in multi-platform usable formats so they could be handled by whatever other motherboard / platform specific update utilities might come to exist.

I ASSUME the UI tools like their control panel overlay and stuff may work on multiple platforms e.g. AMD and Intel CPU motherboards / chipsets and that reads and to some extent sets power / fan / temperature etc. stuff so I assume some of that may be at the level of talking to the GSC if so how does that manage to work
equally on AMD / Intel if not only using PCIE lane connectivity?

If this isn't just a very temporary short term delayed oversight in providing the compatible equitable utilities / protocols or resources for providing e.g. AMD chipset CPU / Motherboard platforms FW update capability but is really some baseless vendor lock in anti-consumer anti-trust BS that they should've known better than to insult their customers with their unwarranted and unreasonable lock in tactics then that's it, I'm done with Intel ANYTHING forever.

Ironically I actually bought an ARC so I could dip my toe in Intel OneAPI / GPU SW etc. development but not to be treated like an irrelevant / unsupported user just because I have some AMD based motherboard / CPU to go along with the Intel GPU I bought for the very reason of OPEN SOURCE / LINUX cross platform support.

I can easily just return the ARC still new in its box and buy an RX 7900XTX and Zen 4 instead and leave "Intel Outside"(C).

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

[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

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

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