The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Intel Management Engine module in Devuan ASCII

Hello:

While checking out the list of errors in /var/log/syslog on another distro (PCLinuxOS), I came across something that caught my eye.
At first I thought it would be something to do only with PCLinux but then I decided to see if it was the same case with Devuan ASCII:

groucho@devuan:~$ lsmod | grep mei
mei_me                 36864  0
mei                   102400  1 mei_me
groucho@devuan:~$ 

... just to see what would happen, tried to remove it:

[root@devuan groucho]#  rmmod mei
rmmod: ERROR: Module mei is in use by: mei_me
[root@devuan groucho]# 

As expected, removing mei_me before removing mei worked and nothing much happened.

I was not sure but it sounded like it was the infamous Intel IME, so I asked:

[root@devuan groucho]# modinfo mei
filename:       /lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei.ko
license:        GPL v2
description:    Intel(R) Management Engine Interface
author:         Intel Corporation
depends:        
retpoline:      Y
intree:         Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions 
[root@devuan groucho]# 

I also asked about what module used it, and I got this:

[root@devuan groucho]# modinfo mei_me
filename:       /lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei-me.ko
license:        GPL v2
description:    Intel(R) Management Engine Interface
author:         Intel Corporation
alias:          pci:v00008086d0000A2BBsv*sd*bc*sc*i*
alias:          pci:v00008086d0000A2BAsv*sd*bc*sc*i*
alias:          pci:v00008086d00005A9Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001A9Asv*sd*bc*sc*i*
alias:          pci:v00008086d0000A1BAsv*sd*bc*sc*i*
alias:          pci:v00008086d0000A13Bsv*sd*bc*sc*i*
alias:          pci:v00008086d0000A13Asv*sd*bc*sc*i*
alias:          pci:v00008086d00009D3Bsv*sd*bc*sc*i*
alias:          pci:v00008086d00009D3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00009CBBsv*sd*bc*sc*i*
alias:          pci:v00008086d00009CBAsv*sd*bc*sc*i*
alias:          pci:v00008086d00008CBAsv*sd*bc*sc*i*
alias:          pci:v00008086d00009C3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00008D3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00008C3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001DBAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001CBAsv*sd*bc*sc*i*
alias:          pci:v00008086d00001E3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001D3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00001C3Asv*sd*bc*sc*i*
alias:          pci:v00008086d00003B65sv*sd*bc*sc*i*
alias:          pci:v00008086d00003B64sv*sd*bc*sc*i*
alias:          pci:v00008086d00002E34sv*sd*bc*sc*i*
alias:          pci:v00008086d00002E24sv*sd*bc*sc*i*
alias:          pci:v00008086d00002E14sv*sd*bc*sc*i*
alias:          pci:v00008086d00002E04sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A74sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A64sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A54sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A44sv*sd*bc*sc*i*
alias:          pci:v00008086d000028F4sv*sd*bc*sc*i*
alias:          pci:v00008086d000028E4sv*sd*bc*sc*i*
alias:          pci:v00008086d000028D4sv*sd*bc*sc*i*
alias:          pci:v00008086d000028C4sv*sd*bc*sc*i*
alias:          pci:v00008086d000028B4sv*sd*bc*sc*i*
alias:          pci:v00008086d000029F4sv*sd*bc*sc*i*
alias:          pci:v00008086d000029E4sv*sd*bc*sc*i*
alias:          pci:v00008086d000029D4sv*sd*bc*sc*i*
alias:          pci:v00008086d000029C4sv*sd*bc*sc*i*
alias:          pci:v00008086d000029B4sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A14sv*sd*bc*sc*i*
alias:          pci:v00008086d00002A04sv*sd*bc*sc*i*
alias:          pci:v00008086d000029A4sv*sd*bc*sc*i*
alias:          pci:v00008086d00002994sv*sd*bc*sc*i*
alias:          pci:v00008086d00002984sv*sd*bc*sc*i*
alias:          pci:v00008086d00002974sv*sd*bc*sc*i*
depends:        mei
retpoline:      Y
intree:         Y
vermagic:       4.9.0-8-amd64 SMP mod_unload modversions 
[root@devuan groucho]# 

I'm running the last available ASCII kernel:

groucho@devuan:~$ uname -ap
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64 GNU/Linux
groucho@devuan:~$ 

All this is the exact same behaviour as in PCLinuxOS with the 4.17.15 kernel.

I'm aware that the only real way to get rid of the IME problem seems to be a complete BIOS overhaul and even then it may be useless as it seems to live inside the chipset. I connect to the web through a WiFi router but I don't think it is much of a barrier.

What I don't understand is the loading of the module by the kernel or even its presence in the filesystem.

I have noticed that it does not seem to be present in the 4.9.0.8 kernel files but as I have noted above, it is being loaded and I can unload it:

groucho@devuan:~$  lsmod | grep mei
mei_me                 36864  0
mei                   102400  1 mei_me
groucho@devuan:~$ su
Password: 
[root@devuan groucho]# rmmod mei_me
[root@devuan groucho]# rmmod mei
[root@devuan groucho]# exit
exit
groucho@devuan:~$ lsmod | grep mei
groucho@devuan:~$ 

.

groucho@devuan:~$ locate mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
---
/usr/include/linux/mei.h
---
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-7-common/include/linux/mei_cl_bus.h
/usr/src/linux-headers-4.9.0-7-common/include/uapi/linux/mei.h
groucho@devuan:~$ 

Does it have a specific purpose, is it actually needed for something in a desktop (or any other) machine?

Seeing that it is not in the 4.9.0.8 kernel files, how it is getting loaded?

I'd appreciate someone with more experience explaining what is happenning and why mei is present in Devuan.

Thanks in advance.

G.

fanderal

Member

Registered: 2017-01-14

Posts: 80  

Re: Intel Management Engine module in Devuan ASCII

I got curious about the same thing not long ago. Like you did, I unloaded the mods and nothing happened. When I found the articles below, I removed and blacklisted those mods. Search 'intel management engine interface spy' for more info.

Intel's Management Engine is a security hazard, and users need a way to disable it (eff)

Intel Management Engine, Explained: The Tiny Computer Inside Your CPU (how to geek)

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: Intel Management Engine module in Devuan ASCII

Hello:

... unloaded the mods and nothing happened.
... removed and blacklisted those mods.

Thanks for the links.
I'm more or less up-to-date wrt this.

But my questions remain:

1.
Why is the Devuan kernel loading the IME module?
What is it necessary for and in what environment?

2.
Why is the module present in the kernel files for 4.9.0-7-amd64 but not for 4.9.0-8-amd64?
Not being in the 4.9.0-8-amd64 kernel files, how is it that it is still being loaded by a running 4.9.0-8-amd64 kernel?

3.
How is it being loaded and how can this be prevented in Devuan ASCII and the upcoming kernels?

Thanks in advance,

A.

fanderal

Member

Registered: 2017-01-14

Posts: 80  

Re: Intel Management Engine module in Devuan ASCII

You're welcome, Altoid.

Why is the Devuan kernel loading the IME module?
It's not Devuan or a distro. It's part of the kernel. I read those articles maybe six months ago and IIRC, disabling the mei and mei_me mods limits my CPU from phoning home.

Why is the module present in the kernel files for 4.9.0-7-amd64 but not for 4.9.0-8-amd64?
I don't know. Thanks for that info. Perhaps the change was a result of all those articles?

What is it necessary for and in what environment?
Intel's stated purpose:
Intel Management Engine Interface (Intel MEI) (kernel.org)

How is it being loaded and how can this be prevented in Devuan ASCII and the upcoming kernels?
I'm still running the stock kernel on Jessie and those two mods don't load. Did kernel devs remove those mods from the newer kernel? Did Intel just include them in their tiny OS so they no longer need to be separately added? I don't know and have no answer to your question. If you find out, please post it.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: Intel Management Engine module in Devuan ASCII

Hello:

Why is the Devuan kernel loading the IME module?
It's not Devuan or a distro. It's part of the kernel.

OK.
But I suppose that (like many other things in the kernel) it can be built with or without mei.

With respect to it not being present in the latest kernel, my apologies:
It happens I made a rather embarrasing mistake.  =^/

I had not done an updatedb prior to the search so the files did not show up as I do not have updatedb set up to run at every boot.
It happens that they are there, sorry for the blunder.

[root@devuan groucho]# updatedb
[root@devuan groucho]# locate mei
---
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-7-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/media/rc/keymaps/rc-gadmei-rm008z.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei-me.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/misc/mei/mei.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/nfc/mei_phy.ko
/lib/modules/4.9.0-8-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
---
/usr/include/linux/mei.h
---
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-7-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-7-common/include/linux/mei_cl_bus.h
---
/usr/src/linux-headers-4.9.0-7-common/include/uapi/linux/mei.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/intel/mei/me.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/mei
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/mei/phy.h
/usr/src/linux-headers-4.9.0-8-amd64/include/config/nfc/pn544/mei.h
/usr/src/linux-headers-4.9.0-8-common/include/linux/mei_cl_bus.h
---
/usr/src/linux-headers-4.9.0-8-common/include/uapi/linux/mei.h

Intel's stated purpose:
Intel Management Engine Interface (Intel MEI)

Yes, I've read it.

I have successfully blacklisted the mei modules so that they will not load at boot time:
https://dev1galaxy.org/viewtopic.php?pid=5782#p5782

But this is just to keep the module from loading at boot time.
As you know it can be eventually loaded by an application or manually as root:

[root@devuan groucho]# lsmod | grep -i mei
[root@devuan groucho]# modprobe mei  
[root@devuan groucho]# lsmod | grep -i mei
mei                   102400  0
[root@devuan groucho]# 

The ideal situation would be that these modules were not in the kernel.

But what I'd like to know is why the Devuan maintainers build the kernel with mei in it.
I have not seen much on the web that says how useful it is.

An then, I'd also like to know what (if any) are the benefits of doing so.

I have the idea that the Devuan forum is not the usual run-of-the mill linux forum (in comparison to say Ubuntu/Mint/etc.)
I think that those of us who have chosen to move to Devuan from Debian or other systemd centric distributions are a bit more 'into-it' so it seems rather odd to me that it is just us two talking about this here, more so if we take into account all that has transpired wrt the Intel Management Engine. 

In any case, I have blacklisted the mei modules and have not seen/detected (apparently and for the moment) any ill effects.
But it's still too early to say for sure.

Thank you very much for your input.

A.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: Intel Management Engine module in Devuan ASCII

But what I'd like to know is why the Devuan maintainers build the kernel with mei in it.

There are no devuan kernels. We use the debian kernels, unchanged. The only packages from debian that get changed are the ones that depend on systemd.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: Intel Management Engine module in Devuan ASCII

Hello:

We use the debian kernels, unchanged.
The only packages from debian that get changed are the ones that depend on systemd.

OK.
I see ...
The Debian kernel has mei built into it.
Is it at all necessary?

I had the idea that Devuan maintainers built the kernel from the source code.
The same way that some people build their own custom kernels.

Thanks for your input.

A.

fanderal

Member

Registered: 2017-01-14

Posts: 80  

Re: Intel Management Engine module in Devuan ASCII

With respect to it not being present in the latest kernel, my apologies

No problem.

But I suppose that (like many other things in the kernel) it can be built with or without mei.

Yes, it can. However, if someone did, they might discover that, say, the CPU firmware (intel-microcode pkg) requires the *presence* of the mei mods to function properly. Too many unknowns down that path for me.

In the How to Geek article, did you check out the links to the ME disabling how-tos? One's on the Gentoo wiki. The other was written by a dev at Purism (sells laptops/phones with PureOS) called 'me_cleaner' on Github.

There are ways around this. I guess each of us has to consider the work in securing the OS (cleaning the kernel, the browser, packet filtering, etc), how much personal info is on the hard drive, and what we're willing to live with.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: Intel Management Engine module in Devuan ASCII

Hello:

No problem.

=-)

... if someone did, they might discover that, say, the CPU firmware (intel-microcode pkg) requires the *presence* of the mei mods ...

Yes, that crossed my mind.

... check out the links to the ME disabling how-tos?

Yes.
But these days I'm wary of any BIOS tinkering.
It's not so easy to recover from a bad burn these days.

24+ years ago, I'd be always ready to risk a mobo for the sake of experimenting with a modded BIOS file.
The half dozen times that things went south I recovered the hardware by hot-plugging the roach into a similar board to reflash it with the original saved file.   

But I'm on a Sun Ultra24 Workstation now and it's enough that the last available BIOS (1.56) is quite buggy.
It actually reports the unit as 'portable' among other assorted issues.

... each of us has to consider the work in securing the OS ...

My idea is that you have to start with what you have control over ie: the OS and it's kernel.
We'll never have control/full knowledge over what is inside the chipset or the CPU.

Who would have thought just three or four years ago that this ME thing actually existed or was even possible to get away with?
A fully operational and independent OS hidden inside the mobo's chipset, ready to start up and run without any evidence in user space or traces left behind.

And I'm convinced that we don't know the half of it ...

Thanks for taking the time to write back.

Cheers,

A.

fanderal

Member

Registered: 2017-01-14

Posts: 80  

Re: Intel Management Engine module in Devuan ASCII

24+ years ago, I'd be always ready to risk a mobo for the sake of experimenting with a modded BIOS file.

Had no idea what a BIOS was back then... my Mac IIcx was just an appliance for work. Was many years later, on a PC, when I had to update the BIOS, but by then the process was an automated point and click.

And I'm convinced that we don't know the half of it ...

I agree. Intel, like the other tech companies that want to know everything about anyone who uses their stuff, is a bit better at concealing how they do it. Privacy used to have a different meaning, but that meaning evolved with the rise of technology, and corporations discovered how to monetize their customers' personal info. I very much appreciate those who have the knowledge to investigate and publish.

Thanks for taking the time to write back.

You're welcome... seems our tinfoil hats are of a similar vintage.

thezeit

Member

Registered: 2018-09-04

Posts: 31  

Re: Intel Management Engine module in Devuan ASCII

I keep thinking Coreboot needs to become the norm for more systems.

I really like the work the puri.sm guys are doing in this regard: https://puri.sm/learn/intel-me/

Blanking the Intel ME at boot (like they are) seems like the bigger hammer to neutralize Intel problems. Hypothetically with the ME still in place... a kernel model wouldn't even necessarily be needed to exploit it (think bad opcodes that could trigger the ME).

I had a buddy with a bunch of rigs he wanted to Coreboot but he put that on pause when he realized he could brick the boards. I'm almost to the point of getting two inexpensive boards of every kind. Noah's Ark style.

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

Re: Intel Management Engine module in Devuan ASCII

Hello:

... Coreboot needs to become the norm for more systems.

No ...
Coreboot needs to become the norm for all systems.

My Sun Microsystems Ultra24 came out with a flawed BIOS, to the extent that it reports itself as a  portable system.
The last (very hard to obtain) BIOS upgrade put out by Sun in the midst of it's gobble up by Oracle was held hostage and did not address this issue which is negligible if you compare it to a severe shutdown issue it has.

groucho@devuan:~$ inxi -Fzx
System:    Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit gcc: 6.3.0) Desktop: Xfce 4.12.3 (Gtk 2.24.30)
           Distro: Devuan GNU/Linux ascii
Machine:   Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01
           Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011

The people who valiantly undertake making Coreboot barely have time and resources for today's boards and then for only a fraction of what is available.
Coreboot should be an industry norm.

Blanking the Intel ME at boot (like they are) seems like the bigger hammer to neutralize Intel problems.

Of course.

... wanted to Coreboot but he put that on pause when he realized he could brick the boards.

Unless you have a sure-fire way of recovering from a failed BIOS flash, you have to assume that you will brick it.
There's many of us in that boat.

Cheers,

A.

thezeit

Member

Registered: 2018-09-04

Posts: 31  

Re: Intel Management Engine module in Devuan ASCII

Unless you have a sure-fire way of recovering from a failed BIOS flash, you have to assume that you will brick it. There's many of us in that boat.

Do you have any experience with the BIOS reset switches on some of the boards?

When looking at EPROM recovery it was noted that some boards have a separate "factory backup" copy of the BIOS embedded in the board such that changing a jumper and powering the board on is suppose to recover the factory BIOS.

I would be willing to even settle for that as an industry norm as it would allow tinkering with considerably less hazard.