You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ME controls firmware authentication on all Intel devices starting with ApolloLake
When the ME is disabled, be it by the OEM or by the user playing with BIOS options, the SOF firmware cannot be authenticated and the firmware boot will fail
We need to find a way to identify this case and separate it from firmware manifest/signature issues
This issue was initially reported by @ford-prefect, and then identified again in #2478
We now get reports that this happens with Fedora 31 and 32
Bottom line: we know of 2 OEMs where the ME is not enabled, and dozens of impacted users. Time to auto-detect the presence of ME and report a clear message "Please enable ME" instead of looking at horrible firmware boot errors.
@plbossart All other firmware loads without the need for ME, why does sof require it?
Can't we do anything to load sof firmware with ME disabled? it's bad to have to depend on that
+1 It looks like a really bad security design to enable audio only when you need to keep running some big unaudited code in CPU.
@ErnyTech that's incorrect, audio/video/vpu need ME authentication.
There's nothing I can do here...
Also I could not get any information on how to detect if the ME authentication is enabled, so I guess I'll have to close this issue - there is no technical solution I am aware of.
@plbossart : Could you add a short hint for users to check the ME settings when the firmware fails to load to the kernel log? Something like DSP firmware cannot be loaded. It may be possible, that the Intel ME (Management Engine) is turned off in BIOS..
@mjg59 we asked users to run tests on a Dell device with the "ME lockout" option and the PCI driver for MEI probed alright, with /dev/meiX devices exposed to userspace, even when allegedly the ME is disabled.
I was really unable to find any reliable information, be it public or from my Intel colleagues, so punted and added wording in the configuration. I don't personally have any time to revisit this topic.
@plbossart The value of config register 0x40 tells you which state the ME is in - bits 16:19 will be 0 if the ME is running normally, something else if it's been disabled. It's possible that Dell have chosen an approach that doesn't set those bits, in which case I'd expect (but can't verify) one of bits 0:3 (current ME state, should be 0x5 if the ME is working), 6:8 (current ME operating state, should be 0x7 if there's an error) or 12:15 (ME error state 0x0 if there's no error) to be set.
@mjg59 I find it ironic that you provided me with information I wish I had a year ago. As I said above I don't have any bandwidth to look further into this, but will gladly review any patches that come my way for integration in the SOF tree then ASoC. Thanks for your understanding.
Activity
perexg commentedon Dec 8, 2020
+1 It looks like a really bad security design to enable audio only when you need to keep running some big unaudited code in CPU.
plbossart commentedon Dec 8, 2020
@ErnyTech that's incorrect, audio/video/vpu need ME authentication.
There's nothing I can do here...
Also I could not get any information on how to detect if the ME authentication is enabled, so I guess I'll have to close this issue - there is no technical solution I am aware of.
perexg commentedon Dec 8, 2020
@plbossart : Could you add a short hint for users to check the ME settings when the firmware fails to load to the kernel log? Something like DSP firmware cannot be loaded. It may be possible, that the Intel ME (Management Engine) is turned off in BIOS..
plbossart commentedon Dec 8, 2020
@perexg yes, I was thinking of a mention for the ME, as well as a note to install the firmware in the first place.
plbossart commentedon Jan 22, 2021
no technical solution to detect ME status, closing.
owlshrimp commentedon Sep 7, 2021
I'm pretty sure that the ME has an interface that shows up on the PCIe bus or similar when active.
mjg59 commentedon Sep 7, 2021
ME status can be determined by reading PCI config register 0x40 on device 00:16.0. If that device isn't present then ME is probably disabled.
plbossart commentedon Sep 7, 2021
@mjg59 we asked users to run tests on a Dell device with the "ME lockout" option and the PCI driver for MEI probed alright, with /dev/meiX devices exposed to userspace, even when allegedly the ME is disabled.
I was really unable to find any reliable information, be it public or from my Intel colleagues, so punted and added wording in the configuration. I don't personally have any time to revisit this topic.
mjg59 commentedon Sep 7, 2021
@plbossart The value of config register 0x40 tells you which state the ME is in - bits 16:19 will be 0 if the ME is running normally, something else if it's been disabled. It's possible that Dell have chosen an approach that doesn't set those bits, in which case I'd expect (but can't verify) one of bits 0:3 (current ME state, should be 0x5 if the ME is working), 6:8 (current ME operating state, should be 0x7 if there's an error) or 12:15 (ME error state 0x0 if there's no error) to be set.
plbossart commentedon Sep 7, 2021
@mjg59 I find it ironic that you provided me with information I wish I had a year ago. As I said above I don't have any bandwidth to look further into this, but will gladly review any patches that come my way for integration in the SOF tree then ASoC. Thanks for your understanding.