Re: RFC: Minimal Intel ME Diagnostic Driver

Hi,


On 8/9/26 12:59 AM, Abdelkader Boudih wrote:
> You can't disable Intel ME at runtime.


I was probably not specific enough - one can disable it - but the 
hardware will poweroff after 30 minutes.

What I meant is stripping it to bare minimum to keep its 'main' loop 
running ... but doing nothing - this is what I understand by 'disabling' 
IME.



>
> The repository you linked doesn’t actually disable ME. It just 
> blacklists the Linux MEI driver, which we doesn’t even have.
>
> The ME firmware itself keeps running regardless of whether the machine 
> is on, asleep, or even soft-powered off. It's a separate 
> microcontroller. It doesn't even need an OS. Ring -3.
>
> Actually disabling (or more accurately, /neutering/) ME requires 
> rewriting the SPI flash with an external programmer to flip the 
> appropriate configuration bit. That bit exists because Intel added an 
> officially supported way to reduce ME functionality for certain 
> customers : NSA, govs and banks...
>
> I built https://github.com/seuros/intel_ma, which combines the 
> functionality of those Python scripts into a single binary, along with 
> a number of additional checks and fixes I have learned on my learning 
> in coreboot.
>
> If you really want to get rid of Intel ME, you generally need older 
> hardware that still supports neutering. Newer generations don’t allow 
> it in the same way. Apple has icloud and AMD has PSP.
>
> As an example of why diagnostics are useful, I recovered around 50 
> computers just last month that were stuck in boot loops (due to 
> watchdog) because a single bit had flipped in the ME region. 
> Reflashing the original bios fixed them immediately.
>
> On Sat, 8 Aug 2026, at 22:50, vermaden wrote:
>>
>> Hi,
>>
>>
>> On 8/8/26 10:23 AM, Abdelkader Boudih wrote:
>>> I am considering adding a small Intel ME driver to FreeBSD.
>>>
>>> I know, Intel ME is everybody's favorite invisible spyware, but hear 
>>> me out.
>>>
>>> The goal is not to implement the full MEI/HECI stack. I mostly want 
>>> basic diagnostic information: firmware version, state, mode, status 
>>> registers, and enough information to tell whether ME is running, 
>>> disabled, in recovery, or unhappy.
>>>
>>> There is a practical reason for this. When ME misbehaves, the 
>>> machine itself can misbehave: watchdog resets, unexpected reboots, 
>>> or other seemingly unrelated failures. I recently fixed a machine by 
>>> reflashing its BIOS after discovering that a single bit in the ME 
>>> region was corrupted.
>>>
>>> It would also be useful for coreboot work. Right now, after 
>>> flashing/corebooting some boards, I often have to boot Linux just to 
>>> inspect the ME state and firmware information.
>>>
>>> The initial driver would intentionally be limited to this diagnostic 
>>> functionality. I don't plan to implement the complete MEI/HECI 
>>> interface, but I would structure the driver so that the necessary 
>>> skeleton is there if somebody wants to extend it later. If Intel 
>>> sponsor anyone for ME support, wants to complete the functionality 
>>> in the future, they would have a reasonable starting point rather 
>>> than having to begin from scratch.
>>>
>>> Before I spend time implementing this, Id like to know whether such 
>>> an intentionally limited driver would be acceptable in the tree. I 
>>> dont want to build it and then discover that it cannot be accepted 
>>> simply because it doesnt implement the entire ME interface.
>>>
>>> Would this scope be acceptable, and is there a preferred place or 
>>> existing interface in the tree that I should build around?
>>>
>>> I have hardware to test it on ME 8 to 16.
>>
>>
>> This is the thing I would really like to see in FreeBSD.
>>
>> It would be great to later even add the possibility to disable this 
>> spyware with this or something similar directly from FreeBSD:
>>
>> - https://github.com/MangoKiwiPlumGrape/intel-me-disable 
>> <https://github.com/MangoKiwiPlumGrape/intel-me-disable>
>>
>>
>> Regards,
>>
>> vermaden
>>

Regards,

vermaden