Can we use ME cleaner on CoreBoot or is it just useless?
2 Likes
:
ME-cleaner is useless to this Intel Gen on L14. If Me-cleaner remove ME on Bios then do not boot.
1 Like
I can’t verify this but Intel implies that all even half-recent Intel CPUs need the Intel ME in order to boot the main CPU.
In other words, I guess, at power-on, the main CPU is not capable of booting itself but the simpler ME CPU is capable of doing a direct boot on power-on, and the ME will then examine the operating environment and initialise things until it reaches a point where it can initiate boot of a main CPU.
As examples of complex scenarios …
- multi-CPU chip mobos (only possible with Xeon?)
- Non-Uniform Memory Access (NUMA) architecture computers?
- and, who knows, maybe even just a vanilla single chip, multi-core CPU?
Then there are questions about the loading of main CPU microcode.
Is it really impossible to design a recent Intel CPU so that it can boot itself even in simple consumer scenarios? I am not qualified to say.
However the real problem is not exactly the existence of the IME but that the IME only runs blackbox code. So there is no way of verifying the safety of the code - for a deeply embedded component.
I would take it as:
- they == the US government or part thereof
- this == a backdoor via the IME
Maybe read from here: Intel Management Engine - Wikipedia
However the following from that link
Intel does not and will not design backdoors for access into its products
is legally questionable. Everyone knows that the US government has the legal authority to make a secret order, with or without the agreement of the FISA court, that would direct Intel to do exactly that, and Intel would find it difficult to resist that using judicial process.
The challenge for the US government with going after Intel in this way is that it would be difficult to meet the stated intention of only targeting “foreigners”. If they went through the FISA court then said court might ask the US government to find a less expansive (more targeted) way. But the problem is that basically everything about FISA court proceedings is secret, so there is no way to know whether such a discussion ever took place etc.
If Intel really held to the above-quoted position, it is not entirely clear whether they could legally respond by closing down. However that would be a very difficult position to adhere to. For example, they might be in breach of their legal obligations to shareholders if they closed down in such a scenario.
That might leave Intel with the only remaining options as
- comply, or
- relocate out of the US (and who knows whether the US government could block that)
If you think that Big Tech senior management or even Little Tech senior management is going to die in a ditch for your privacy and security then I think you are kidding yourself.
For all the above, Intel could dispel the smell by opening up the IME (at least to the extent as outlined above by me).
1 Like
How have you established that?
1 Like
Technically there are two aspects to ME cleaner
- removing unnecessary modules
- using the HAP bit to send the IME to sleep Edit: i.e. disable after boot of the main CPU
Only the former is useless on that Intel Gen CPU (and presumably all later generations), as I understand it.
2 Likes
It was strictly engineered to the purpose: free backdoors, but we never know.
HECI is for sleep, which can still wake up without user consent. HAP is for Disabled permanent and still permit to boot.
1 Like
Thanks for the correction. I updated my post to be clearer.
I assume by “permanent” you mean … until next power-on.
2 Likes
Doesn’t nuke the whole ME region. Always dump a .bin of a BIOS if you’re going to modify it… And always keep a .bin.bak to make sure you have a dump that is known-good…
2 Likes
2 Likes
Tunnel vision is a dangerous thing when it comes to security. Sure, it’s good to focus on things sometimes but it leaves you blind for everything else. Even though is seems smart to stare at “ME(NSA)” backdoors [I mean, it was there in the title, I couldn’t resist 
], you should never assume that A) any modern complex device can not have flaws that can be exploited, intentional or not (this is why we have layered security - nothing is foolproof, just fool resistant), B) even if one isn’t known now, something weak or odd could be found later, C) there can always be more than one (and +1 [or +N]), and D) that just one specific entity could use them [“+1” rule here too] (this is the problem with all the arguments of intentional backdoors also - bad actors will always get access too and even good actors with good intentions are likely to turn into bad ones - even if just for one time). Also, a single weakness by itself is not enough (due to layers but also environment complexities) to make a system useless or fully insecure (relative to risk profile).
2 Likes
While I agree that tunnel vision is dangerous … the concern about the IME is that it operates at such a low level, having complete control over almost everything.
As a perhaps hypothetical concern … any code that runs even before the main CPU’s boot firmware could probably run the boot firmware in a virtualised environment, such that the boot firmware doesn’t even realise that it isn’t running on bare metal, and that could have some pretty interesting implications for security.
However the IME doesn’t even really need to do that because it has ongoing low level access to almost everything - and can subvert almost all other security measures.
3 Likes
I disagree. The CSME (ME) is a completely separate CPU/SOC, a 32 bits Quark architecture Pentium (old!). It could not execute any of the real CPU boot sequence nor firmware - only the main CPU can do its own reset vector and bootblock stage. Furthermore, running a virtualised environment inside ME is not possible: it has no vmx flag and can’t do virtualisation. And also it has no memory except its tiny on-dye 1.5MB SRAM, until DRAM init is done (which is coreboot’s romstage fsp-m init_memory call) and this must execute on the main CPU.
But this was only a hypothetical concern, just as you said - I just wanted to explain why this would not be a feasible bypass.
1 Like
I didn’t mean “virtualised inside the ME”. I meant virtualised on the main CPUs.
You raise a good point about whether the IME can access memory before the main CPU has done DRAM init - because the IME does normally have full access to the memory.
1 Like
For the more technically inclined, a detailed description of the IME and CPU interactions after power-on:
As can be seen, after its reset vector the ME co-processor has no RAM except for its own on-dye 1.5MB SRAM. At this point, it can only load (from the SPI flash ME region) the 4 basic modules needed for starting the main CPU and then have it connect and train DRAM (an incredibly complicated process on modern cores.)
But it does nothing in the meantime, waiting for the main CPU to send the DID (DRAM_Init_Done) signaling that DRAM is now available - after this, it can load many more modules, runtimes and tasks from SPI ME region.
The 4 basic modules loaded before more memory is available, are: RBE, KERNEL, SYSLIB and BUP.
RBE (ROM Bypass Enable) is updated boot ROM code which will bypass the on-dye mask-ROM; its purpose is to correct eventual bugs/vulns found in the original ROM code, which cannot be replaced on the SOC dye.
KERNEL and SYSLIB are the (modified) MINIX 3 micro-kernel. All 3 modules run at ring 0 and BUP in less privileged userland for separation/isolation.
This BUP module (BringUP) is the code that sets up the hardware for the main CPU to do its reset vector at 0xFFFFFFF0 (16 bytes below the 4GB top of addressable memory hardware-mapped to SPI flash by the PCH.) This internal mapping corresponds to the SPI flash BIOS region, hence it is the coreboot BootBlock, the first instructions the main CPU executes - we have control very early in the boot process!
It is only after coreboot’s bootblock stage execution that romstage will call FSP-m binary blob, which will setup MMU and train DRAM. When init_memory call returns - and only then - we have the DRAM online and DID signal sent to ME.
During all the time while the CPU runs the above-mentioned initial coreboot stages, the ME does absolutely nothing but wait for DID signaling that memory is available. It can then load more modules.
That is: if there are more modules to be loaded, because with Nicola Corna’s me_cleaner, everything else could be removed from the SPI flash ME region, an extraordinary achievement (neutralization) that guaranties no other ME code can run but for those 4 required modules.
Addendum: the above explanation relates only to ME firmware 11.xx, Skylake and Kabylake 6th and 7th gen (later Librem 15/13 models.) Unfortunately things are more complicated for later generations (e.g. Librem 14), due to the inability to cleanse and therefore neuter unwanted/undocumented code from ME; a huge attack surface in ring -3 compared to ME 11.xx firmware family.
In a sense, late Librems 15/13 will remain for a long time the safest and smallest attack surface to remedy the hard to solve IntelME problems and uncertainties.
4 Likes
Full citation of image slide?
1 Like
The Phantom Menace: Intel ME Manufacturing Mode. Mark Ermolov & Maxim Goryachy
Hitbsecconf2018 pdf at https://conference.hitb.org/hitbsecconf2018dxb/materials/D1T1%20-%20The%20Phantom%20Menace-%20Intel%20ME%20Manufacturing%20Mode%20-%20Maxim%20Goryachy%20and%20Mark%20Ermolov.pdf
4 Likes
I see, it was one of the many inline references from a blog article I linked recently on the Purism community forums:
See also:
Yes, I read everything Eclypsium publishes and that’s probably (I can’t remember for sure) where I found a reference to this excellent presentation at Hack-In-The-Box 2018 from Mark Ermolov & Maxim Goryachy of Positive Technologies
1 Like
I miss the diamond that asks “Load from Tape or DIsc?”
1 Like
See also:
1 Like