Re: RFC: Minimal Intel ME Diagnostic Driver

On Sat, Aug 8, 2026 at 1:24 AM Abdelkader Boudih <[email protected]> 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.
>

Yes, it would be worthwhile.  Just consider inputs somewhat
adversarially, both for ME bugs and the corruption you note.