Artix Linux Forum

I built a custom kernel (4.14.12) with Intel MEI disabled. I have no /dev/mei,
and my system seems to work fine. But can it be that easy to disable the malware?
Here is the output of nmap:

sudo nmap -p 16991-16995,623,624 localhost
PORT      STATE  SERVICE
623/tcp   closed oob-ws-http #not sure this and the next are relevant
624/tcp   closed cryptoadmin
16991/tcp closed intel-rci-mp
16992/tcp closed amt-soap-http
16993/tcp closed amt-soap-https
16994/tcp closed amt-redir-tcp
16995/tcp closed amt-redir-tls

That seems to look good, but everything I read on the www to disable this junk
is like "get a raspberry, install a special image, flash your firmware etc, etc"
which sounds definitely dangerous and difficult. It might even be dangerous to
disable ME at this point, as Intel might distribute firmware updates against
meltdown/spectre in this way. How can I know? I installed the recent intel-ucode
update (intel-ucode 20180108-1), but dmesg says "microcode updated early to
revision 0xc2, date = 2017-11-16", so that's probably not the update I was looking
for.

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
00:14.0 USB controller: Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller (rev 31)
00:16.0 Communication controller: Intel Corporation Sunrise Point-H CSME HECI #1 (rev 31)
00:17.0 SATA controller: Intel Corporation Sunrise Point-H SATA controller [AHCI mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-H PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-H LPC Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-H PMC (rev 31)
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)
00:1f.4 SMBus: Intel Corporation Sunrise Point-H SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-V (rev 31)

from dmesg:

efi: EFI v2.50 by American Megatrends
DMI: Wortmann_AG TERRA_PC/H110M-A/M.2, BIOS 3407 04/18/2017

from config (I disabled everything with MEI in it):

...
# CONFIG_INTEL_MEI is not set
# CONFIG_INTEL_MEI_ME is not set
# CONFIG_INTEL_MEI_TXE is not set
...

Secure boot is disabled. I'll post more info as needed.

you may be disabling some kernel modules but you're not in fact disabling the hardware MEI
disabling the MEI hardware would completely disable your ability to boot the computer, per the intel docs

Yep! What @toxygen said; and incidentally, there was an FSF post about this just the other day: https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom

I knew all that. I just built and installed linux-libre, and it seems to work perfectly (I don't even need linux-firmware or inetutils, I took those out of the dependencies a while ago), but it is way old (4.14.0), and it doesn't load the recent ucode update, so I don't think it is safe to use. Kind of annoying, with all the noise they make.

It is worth printing:

*Read and share online:
<https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom>*

Dear Ruben Safir,

"The Management Engine (frequently abbreviated as ME) is a separate
computer within Intel computers, which denies users control over their
computers, by forcing them to run nonfree software that cannot be
modified or replaced by anyone but Intel. This is dangerous and
unjust. It is a very serious attack on freedom, privacy, and security
of computer users."

So writes Denis GNUtoo Carikli, free software activist and one of the
co-founders of the Replicant project in a recent article titled "[The
Management Engine: an attack on computer users' freedom][1]."

[1]:
https://www.fsf.org/blogs/sysadmin/the-management-engine-an-attack-on-computer-users-freedom

Intel ME lives inside every computer with an Intel chipset. As a
major producer of home and commercial computing technology, Intel ME
can seem not just pervasive, but ubiquitous. This infringement of
freedom is in homes around the world -- and there's nothing that can
be done about it.

With security issues like the [Spectre and Meltdown][2]
vulnerabilities discovered in Intel chips -- the most popular chipset
among x86 users -- it's become more important than ever to talk about
the necessity of software freedom in these deeply embedded technologies.

[2]:
https://www.cnet.com/news/meltdown-spectre-intel-ceo-no-recall-chip-processor/

In order to help a larger audience understand Intel Management Engine
and the way it affects developers and users alike, Carikli began
working on a book, a section of which he shared with the FSF for
publication.

You can [read and share this article online at FSF.org][1].

Cheers,
Molly

--
* Follow us at <https://status.fsf.org/fsf>. * Subscribe to our RSS
feeds at <https://fsf.org/blogs/RSS>.
* Join us as an associate member at <https://www.fsf.org/jf>.

Sent from the Free Software Foundation,

51 Franklin St, Fifth Floor
Boston, Massachusetts 02110-1335
UNITED STATES


You can unsubscribe from this mailing list by visiting
https://my.fsf.org/civicrm/mailing/unsubscribe?reset=1&jid=156008&qid=31625209&h=ea8e90f2eeed79fe.

To stop all email from the Free Software Foundation, including Defective
by Design,
and the Free Software Supporter newsletter, visit

https://my.fsf.org/civicrm/mailing/optout?reset=1&jid=156008&qid=31625209&h=ea8e90f2eeed79fe.
_______________________________________________
Hangout mailing list
Hangout@nylxs.com
http://lists.mrbrklyn.com/mailman/listinfo/hangout

Here is the output of intelmetool after the recent ASUS UEFI update:

Bad news, you have a `Sunrise Point-H LPC Controller` so you have ME hardware on board and it is very difficult to remove, continuing...
RCBA at 0x00000000
MEI not hidden on PCI, checking if visible
MEI found: [8086:a13a] Sunrise Point-H CSME HECI #1

ME Status   : 0x90000245
ME Status 2 : 0x86110306

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : Clean Moff->Mx wake
ME: Power Management Event  : Pseudo-global reset
ME: Progress Phase State    : Unknown 0x11

PCI READ [bc] : 0x000000bc
ME: Extend Register not valid

ME seems okay on this board
WRITE    [00] : CB: 0x80040007
WRITE    [00] : CB: 0x000002ff
READ     [08] : CB: 0x801c0007
READ     [08] : CB: 0x000082ff
READ     [08] : CB: 0x000b0006
READ     [08] : CB: 0x000a04ac
READ     [08] : CB: 0x000b0006
READ     [08] : CB: 0x000a04ac
READ     [08] : CB: 0x000b0000
READ     [08] : CB: 0x000a03ea
ME: Firmware Version 11.6.1196.10 (code) 11.6.1196.10 (recovery) 11.0.1002.10 (fitc)
WRITE    [00] : CB: 0x80080007
WRITE    [00] : CB: 0x00000203
WRITE    [00] : CB: 0x00000000
READ     [08] : CB: 0x800d0007
READ     [08] : CB: 0x00008203
READ     [08] : CB: 0x00000000
READ     [08] : CB: 0x11154004
READ     [08] : CB: 0x00000031
ME Capability: Full Network manageability                 : OFF
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : OFF
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : OFF
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : ON
ME Capability: ICC Over Clocking                          : OFF
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : OFF
ME Capability: KVM Remote Control (KVM)                   : OFF
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : ON
ME Capability: TLS                                        : OFF
ME Capability: Wireless LAN (WLAN)                        : OFF
exiting

The only stuff that seems dicey to me is "Protected Audio Video Path" and
"Virtual LAN (VLAN)" (because I don't understand what it means). It seems after
the bad publicity Intel (or ASUS) seems ready to at least partially defang ME,
but of course I am not an expert. There is also something about "Trusted platform"
in the UEFI, but I left it disabled (again, don't know what it means).

I think you want this to check it:
https://www.intel.com/content/www/us/en/support/articles/000025619/software.html

AFAICT microcode updates have been used by Intel since 1995, AMD since 1999. The microcode is installed in ROM when the chip is manufactured. It also has RAM where microcode updates can be installed, and the updates augment or replace some or all of the onboard ROM microcode. These updates must be loaded at every boot because RAM needs a constant power supply.
 Initially this was done by the BIOS, more recently it could be done by the OS as well, to make it easier. But if you have a computer which is new enough to still receive BIOS updates then you might be able to get the updated microcode by updating the BIOS if or when this becomes available. The above Intel tool might not detect a BIOS update, also I don't know how selecting UEFI vs BIOS boot might affect things, you would need to research your particular hardware carefully I guess. The link below includes a way to see what microcode version is loaded :

https://support.mozilla.org/en-US/kb/microcode-update

For those not covered by this then I guess this quite a significant development, as a large number of Intel machines just became insecure on all FSF approved distros and for anyone else using a libre kernel.

Relevant:
https://github.com/corna/me_cleaner/issues/3 (https://github.com/corna/me_cleaner/issues/3)
The community is testing various boards, most success stories are posted on that thread. Building a kernel with that option disabled does not influence it in any way. The intel-ucode package is not ME related and does not disable it, you probably want the latest microcode on all systems. Proceed with caution, actual risk of bricking hardware awaits. Disabling ME does not prevent the system from booting, there are various parameters and disablement levels, depending on vendor implementations.

Yes, ignore some of my previous post, although the Intel check was relevant. I just realized this is a different Intel CPU vulnerability and not related to M&S after reading this:
https://en.wikipedia.org/wiki/Intel_Management_Engine
It's difficult  to keep up with them all...  :-[  Loading the Management Engine and loading Microcode are separate issues I think.
I saw some discussion on the GUIX mailing list saying that although they weren't going to ship microcode it is sort of a grey area according to FSF guidelines and if users wanted to update it for security reasons by installing the firmware package themselves that would be fine.

Well, philosophical reasons of some distributions aside, motherboards that still receive bios updates actually bundle the microcode inside it as well as ME. With the latest CPU security issues, practicality trumps all. Unless you're running a system that never connects to any network at all, you need both the latest intel microcode and ME versions or you're exposing yourself to known vulnerabilities. Now, if you manage to disable ME on your motherboard after you update it, that's a win-win. I got unlucky so far.

I don't know if hypocrisy is the right word, but the whole 'we don't ship binary blobs because they're bad, even if strangers can remotely access your computer if you don't have the blobs' makes me think of religious cults.

Well, this quote from the discussion sort of explains it, I think they are saying it ought to be open source so you should ideally get hardware that doesn't require this. It looks like disabling ME (if possible) but having the latest microcode is the best for security on affected CPU's (except those that have the reboot bug) or better still use an unaffected CPU  :)
http://lists.gnu.org/archive/html/guix-devel/2018-01/msg00219.html
At what point does a microcode update start to resemble just another
software update (like firmware updates have become)?  I suspect that
point is very close at hand, if it has not already arrived.  In his
essay on how to apply the free software criteria, Stallman writes [9]:

"A computer can have modifiable preinstalled firmware and microcode at
lower levels. It can also have code in true read-only memory. We decided
to ignore these programs in our certification criteria today, because
otherwise no computer could comply, and because firmware that is not
normally changed is ethically equivalent to circuits. So our
certification criteria cover only the code that runs on the computer's
main processor and is not in true read-only memory. When and as free
software becomes possible for other levels of processing, we will
require free software at those levels too."

The last sentence is telling.  It sounds to me like he's arguing that
once it becomes as easy to update your microcode as it is to update any
other software on your computer, that microcode qualifies as software,
so we should require it (the microcode) to be free software.  However,
he also said that the "we decided to ignore these programs [modifiable
preinstalled firmware and microcode] in our certification criteria
today, because otherwise no computer could comply".  Does this mean that
microcode is still outside the scope of free software today, and that it
would be OK for Guix to advocate installing a non-free microcode update?
Personally, based on what I currently know, I suspect that no
FSDG-compliant distribution, like GuixSD, can promote a non-free
microcode update, because microcode that can be easily updated is really
just software.

Absolutely agree, ought to be free. But they're not making the hardware, they don't have actual deals with CPU manufacturers or any sort of leverage. So it probably won't be.

I love the philosophy of opening everything, it's just not something doable today.

My understanding is that the microcode is supposed to be too small to be malicious or have any advanced functionality inside it. ME/AMT, different story. And don't forget network card firmware ... ME is supposed to be able to communicate with Intel NICs.

The much touted libre 'Talos' workstation (not cheap) is actually affected by execution prediction bugs similar to those on Intel. But at least it's more free. I also remember heartbleed, as far as open source security goes. I hope the next-gen intel/amd cpus will have more options to disable.

IIRC some Asus (prime) motherboards came with a jumper to disable ME from the start and there's also Purism that does some smart hardware thing to kill off most of it, not just on the software side. There's also some hack with shorting the pins on realtek sound cards at system boot to unlock the region (and presumably disable it for that boot sequence).

https://www.bios-mods.com/forum/Thread-UEFI-Dell-XPS-15z-L511z-modded-BIOS-and-HOWTO?pid=52669#pid52669 (https://www.bios-mods.com/forum/Thread-UEFI-Dell-XPS-15z-L511z-modded-BIOS-and-HOWTO?pid=52669#pid52669)

There's no reason for ME to exist on home desktop computers of private individuals. For enterprise management, maybe. But with all the conspiracy theories, no malicious intent has actually been proven.

I think you sorely underestimate what even a few lines of code can do.

rm -rf /

actually, all code is a few lines of code.  You have a stack, a point, an arethmaic processor, and a set of random access memory.

http://www.computerweekly.com/feature/Apollo-11-The-computers-that-put-man-on-the-moon

It's not that I'm trying to defend what I've posted or that I'm nickpicking, but I feel that I need to shed some perspective upon this.

rm -rf / 

is actually not one line of code. it requires a running shell, a fully compiled rm binary, a running kernel with the appropriate filesystem  module loaded and a whole lot of memory to keep the state of the OS in.

At the point of actually loading the microcode, none of that is true for the main CPU.

I don't underestimate what even a single bit flip can do, I'm not even saying it's not something to be worried about, but with the obscurity of essential parts of CPUs, it's way too easy for unfounded speculation to become "common knowledge", with everything bad that comes out of it.

This isn't even apples to oranges. It's a few lines of low level machine code on uninitialized hardware. Perspective.

Of course, this is my opinion on the microcode alone.

There's ample space elsewhere to put bad stuff in, I don't believe the microcode is it.

But I also subscribe to the camp that believes malicious intent should be proven, not implied by default. Yes, I'm aware that different people define "malicious" in different ways. I was unable to prove that my computer is doing stuff it shouldn't. That could say a lot about my (in)ability, but I have yet to see proof of intentional backdooring from anyone.

Note that the ME does not fall under "stuff it shouldn't", because it's well documented. I falls under "stuff I would really like removed because it is reasonably suspicious".

I have yet to see millions of people protesting against Intel, ME is not hidden from the consumer, so people know what they are buying. This issues is (strangely) subject to the vote of the mass consumer.

<<This isn't even apples to oranges. It's a few lines of low level machine code on uninitialized hardware. Perspective.>>

all true accept rm -rf  / translates to only six bytes of code on the hardware level ;) depending on the file system.  Less to just zero out the physical hard drive.  That would be 3 bytes, I believe.  Fetch the address of the first HD local, and send 00000000.  increment the memory location, repeat.

no os is even needed.

<<But I also subscribe to the camp that believes malicious intent should be proven, not implied by default. >>

Yeah, I never really understood this when the malicious intent in there is plain sight and there only extortionist rationality available for an action.  When you ask to not make edge a default browser, and you can't remove it, and MS asks you, how bout this FUD?  Are you sure you want Firefox to be your default browser?  They are telling you their intent.  They are not your mother.  These companies are systematic rapist who's purpose is to strip you of every aspect of your every aspect of your worth.  Your  interaction with them since designed to  be for their  gain, and it is an inelastic economic relationship.

"I have yet to see proof of intentional backdooring from anyone"
Shadowbrokers and Edward Snowden are quite convincing. Remember Eternal Blue?  :D
https://en.wikipedia.org/wiki/EternalBlue
The trouble with leaving back doors open is other people can go round the back and walk in too, so it is generally better to avoid this if possible. But weighing microcode updates with possible unknown issues vs the known and published M&S exploits then a microcode update to fix it (if relevant) seems the safest option to me.

This is false. rm does not overwrite the device with zeros. It keeps the filesystem in its place and in most cases, even allows for files to be recovered further down the road. You are severely distorting reality to suit your argument. That command itself needs to be path aware (/), needs to parse arguments, needs to know about filesystem directories to be recursive. I even wonder how overwriting a device with zeros could be considered a backdoor. I thought something like remote access of some kind was needed for that definition. Or at least something more than mindless data destruction.


I'm surprised at the direction this conversation is taking, I'll take a break from Artix for a while. By the very same logic you're using, Artix may well be backdoored by intentional holding back of packages compared to the Arch repos, with known vulnerabilities. Or by the lack of transparency of the build process. Or hey, look! No public CVE bug tracker and no dedicated security team! We're all doomed!

I'm not saying it is (backdoored), but it's your logic, applied on a different context. Because you can't check it, then it's bad, right? As simple as that! How could you possibly tell the machines doing the compiling aren't controlled by some agency you're afraid of! omg!



We were talking about ME and micrcocode, not Microsoft's SMB protocol, right? And even then, are you saying MS did that on purpose? Proof?

I know that as far as computer security goes, whitelisting > blacklisting, any day of the week. But if you want to change the status quo, you have to work with the social and legal system, and that means proving guilt, not proving innocence.

Have fun!

PS: remember that time you ordered an HDD or SSD and it was delivered to your home? _THEY_  intercepted the pakage in transit and changed the firmware on it, so that on boot it will load an invisible backdoor from a file hidden in the firmware, giving _THEM_ root access, loaded with the kernel. Yes, on _ALL_ the storage devices _EVERYWHERE_. They call it the Just Intercept Everything In Transit And Replace The Firmware So That We Would Have Too Much Data (lovingly known as JIEITARTFSTWWHTMD)

/me wonders about backdooring usb powered IOT adult toys....

Take that, silicone-covered ARM firmware, I will overwrite you with ZEROS!

No, I am not arguing with you at all.  And after that diatribe that I didn't read past this point, I am arguing even less with you now.  I thought there was a worth while conversation to be had here, but I was mistaken.  To the most part, this has been a freindly forum for artix users.  There was no need for this confrontation, and I feel you have perversed what I wrote inorder to find an argument that I don't want to participate in.

From the link I provided above:
"According to Microsoft, it was the US's NSA that was responsible, by dint of its controversial strategy of "stockpiling of vulnerabilities", for, at the least, preventing Microsoft from timely public patching of this, and presumably other, hidden bugs."
If you had looked into the shadowbrokers NSA rootkit which they published (I can understand why you didn't though  :D ), you would have seen there was a Linux and also Windows section. Rather than being one single thing, it was more like a set of shell commands, in that each element was insignificant and unobtrusive, yet together they could be applied to do something. So what to us may look like a bug could in fact be a secret vulnerability. Or it may just be a bug.
It required extra elements to be added to use though - the standard OS had the potential to be compromised, but it was not compromised by default.
And luckily Linux is updated so while the Shadowbrokers tools may still work against Windows XP those particular issues have been long since fixed for us. But I think it was a good example of how these things work, and proves that they are real.
I do apologize if I have caused any offence though, my comments were intended in an entirely cheerful and friendly way, you are free to hold and express your own opinions! I have found your contributions to this forum to be interesting and helpful.

It was complaining to you.  I'm aware of the NSA activity and I think I've written quite a bit about it since and before snowden.  Generally I am with you, and share your remorse over both government and corperate intrusions on security and privacy.