I'm experimenting with what happens if I remove the ME firmware from from the lower SPI flash chip on my Thinkpad x230. If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes without any complaints.
The boot script then kexec's into Xen and Qubes, which works, but things like S3 sleep don't seem to kick in when I close the lid ("unknown key pressed", code e058). systemctl suspend works fine and the system wakes up when I open the lid again, so this might might be a spurious issue.
If I erase the entire ME region from 0x3000 to 0x4FFFFF the system will not boot at all. The indicator on the power button will flash when I press it, but the system does not seem to respond otherwise (I do not have a port 80 debugger or hardware serial port to see where it is failing). Reflashing with the original ME firmware restores it's functionality.
That's pretty interesting. I had no idea that would work.
I wonder if erasing it all erases that little boot of the ME you need to get the hardware going, whereas the 4KB erase lets the little bootstrap run but disables the ME otherwise. If so, that's great news.
ron
On Mon, Sep 12, 2016 at 8:43 AM Trammell Hudson hudson@trmm.net wrote:
I'm experimenting with what happens if I remove the ME firmware from from the lower SPI flash chip on my Thinkpad x230. If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes without any complaints.
The boot script then kexec's into Xen and Qubes, which works, but things like S3 sleep don't seem to kick in when I close the lid ("unknown key pressed", code e058). systemctl suspend works fine and the system wakes up when I open the lid again, so this might might be a spurious issue.
If I erase the entire ME region from 0x3000 to 0x4FFFFF the system will not boot at all. The indicator on the power button will flash when I press it, but the system does not seem to respond otherwise (I do not have a port 80 debugger or hardware serial port to see where it is failing). Reflashing with the original ME firmware restores it's functionality.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Trammell Hudson wrote:
I'm experimenting with what happens if I remove the ME firmware from from the lower SPI flash chip on my Thinkpad x230.
AFAIK the ME will allow the platform to stay on for 30 minutes, and will then shut it down hard.
This has been observed by people in the coreboot community, I haven't personally seen it, and I don't know exactly how the shutdown happens, but I assume it involves pulling a signal to the chipset.
The 30 minutes are meant to give a technician some time to restore the platform into a functional state.
If you are interested in the ME I strongly recommend reading through the entertaining book Platform Embedded Security Revealed, free download at apress.com, redistributable for non-commercial purposes only. ISBN 9781430265719 or 9781430265726.
If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes without any complaints.
Does it stay operational for more than 30 minutes?
systemctl suspend works fine and the system wakes up when I open the lid again, so this might might be a spurious issue.
Does it resume after more than 30 minutes from power-on? And from suspend?
If I erase the entire ME region from 0x3000 to 0x4FFFFF the system will not boot at all.
Not sure that's because of ME, but could be.
The indicator on the power button will flash when I press it,
That is an LED connected to the EC, unrelated to the x86 platform.
but the system does not seem to respond otherwise (I do not have a port 80 debugger or hardware serial port to see where it is failing).
To look into the ME in a lot of detail I think you may need to get involved with the hardware.
//Peter
On Mon, Sep 12, 2016 at 06:13:16PM +0000, Peter Stuge wrote:
If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes without any complaints.
Does it stay operational for more than 30 minutes? [...] Does it resume after more than 30 minutes from power-on? And from suspend?
Yes, it has been operational for the past few hours and I'm able to suspend it with 'systemctl suspend' and resume with the lid or power switch. I think the lack of entering S3 on lid-closure might be a Qubes 3.2-rc regression, so I'm ignoring that for now.
[...]
The indicator on the power button will flash when I press it,
That is an LED connected to the EC, unrelated to the x86 platform.
That makes sense. I also note that if I have the device on external power the light stays on, but there is no external sign of life.
but the system does not seem to respond otherwise (I do not have a port 80 debugger or hardware serial port to see where it is failing).
To look into the ME in a lot of detail I think you may need to get involved with the hardware.
What hardware probes would you recommend? Do you know of any easy place to attach them? The x230 has a second mini-pcie slot available if there are useful debugging devices.
Here's the relevant sections from the 'cbmem --console' -- the early ME init routines appear to find a bad partition table, but for some reason the later call to intel_me_status() reports it as ok. I don't see any sort of backup $FPT structure in the ROM, so I'm not sure what is it using.
coreboot-4.4-1458-gae58906-heads Fri Sep 9 15:14:17 UTC 2016 romstage starting... Setting up static southbridge registers... done. Disabling Watchdog reboot... done. Setting up static northbridge registers... done. Initializing Graphics... Back from sandybridge_early_initialization() SMBus controller enabled. CPU id(306a9): Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz AES supported, TXT supported, VT supported PCH type: QM77, device id: 1e55, rev id 4 Intel ME early init WARNING: ME has bad firmware ME: Requested 32MB UMA ME: FW Partition Table : BAD ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Recovery ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : Waiting for DID BIOS message ME: FWS2: 0x101f016a ME: Bist in progress: 0x0 ME: ICC Status : 0x1 ME: Invoke MEBx : 0x1 ME: CPU replaced : 0x0 ME: MBP ready : 0x1 ME: MFS failure : 0x1 ME: Warm reset req : 0x0 ME: CPU repl valid : 0x1 ME: (Reserved) : 0x0 ME: FW update req : 0x0 ME: (Reserved) : 0x0 ME: Current state : 0x1f ME: Current PM event: 0x0 ME: Progress code : 0x1 PASSED! Tell ME that DRAM is ready
[...]
XHCI: Setting up controller.. done. PCI: 00:14.0 init finished in 205 usecs PCI: 00:16.0 init ... ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Reset ME: Current Operation State : Preboot ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : BEGIN intel_me_path: mbp is not ready! ME: BIOS path: Error
Trammell Hudson wrote:
My Linux payload initializes without any complaints.
Does it stay operational for more than 30 minutes? [...] Does it resume after more than 30 minutes from power-on? And from suspend?
Yes, it has been operational for the past few hours
That's interesting. It would be interesting to find out more about the state of the ME in this case. Maybe the cleared section isn't part of it's firmware, or maybe it really doesn't care, though that would surprise me.
I think there's an ME utility in the coreboot source tree. The ME host interface isn't very well-documented AFAIK, but the kernel has a little bit of code too.
I think the lack of entering S3 on lid-closure might be a Qubes 3.2-rc regression, so I'm ignoring that for now.
Agree.
To look into the ME in a lot of detail I think you may need to get involved with the hardware.
What hardware probes would you recommend?
One thing is the LPC bus. It doesn't have that much to do with the ME per se, but I believe it's live from reset and so has early activity.
Another is the boot flash SPI. See what addresses get fetched.
I don't have a concrete tool to recommend, I am developing one, but for the immediate term what you can buy is essentially expensive logic analyzers with LPC and SPI decoders. :\
Do you know of any easy place to attach them? The x230 has a second mini-pcie slot available if there are useful debugging devices.
The X230 has pads for a "debug card connector" which may be labeled CN14 on the mainboard, with LPC bus, IRQSER and a bit of power control.
There are also edge pads "golden finger" with roughly the same signals.
Neither the WLAN nor the WWAN Mini-PCIE slot have LPC signals.
Here's the relevant sections from the 'cbmem --console'
Sorry, I haven't gotten to the details from the PCI side.
I'm not sure what is it using.
Is the partitioning relevant for the ME? I'm not sure that it is.
ME: Current Working State : Recovery ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase
..
ME: Current Working State : Reset ME: Current Operation State : Preboot ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase
How do the above change, if at all, with unchanged flash?
//Peter
On Mon, Sep 12, 2016 at 07:11:41PM +0000, Peter Stuge wrote:
[...] It would be interesting to find out more about the state of the ME in this case. Maybe the cleared section isn't part of it's firmware, or maybe it really doesn't care, though that would surprise me.
The $FPT has pointers to various sections or handlers, it seems. I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary search how much of the firmware it needs...
ME: Current Working State : Recovery ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase
..
ME: Current Working State : Reset ME: Current Operation State : Preboot ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase
How do the above change, if at all, with unchanged flash?
With the firmware partition table restored:
coreboot-4.4-1458-gae58906-heads Fri Sep 9 15:14:17 UTC 2016 romstage starting... Setting up static southbridge registers... done. Disabling Watchdog reboot... done. Setting up static northbridge registers... done. Initializing Graphics... Back from sandybridge_early_initialization() SMBus controller enabled. CPU id(306a9): Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz AES supported, TXT supported, VT supported PCH type: QM77, device id: 1e55, rev id 4 Intel ME early init Intel ME firmware is ready ME: Requested 32MB UMA Starting native Platform init
[...]
ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : Waiting for DID BIOS message ME: FWS2: 0x101f012c ME: Bist in progress: 0x0 ME: ICC Status : 0x2 ME: Invoke MEBx : 0x1 ME: CPU replaced : 0x0 ME: MBP ready : 0x1 ME: MFS failure : 0x0 ME: Warm reset req : 0x0 ME: CPU repl valid : 0x1 ME: (Reserved) : 0x0 ME: FW update req : 0x0 ME: (Reserved) : 0x0 ME: Current state : 0x1f ME: Current PM event: 0x0 ME: Progress code : 0x1 PASSED! Tell ME that DRAM is ready ME: FWS2: 0x102c012c ME: Bist in progress: 0x0 ME: ICC Status : 0x2 ME: Invoke MEBx : 0x1 ME: CPU replaced : 0x0 ME: MBP ready : 0x1 ME: MFS failure : 0x0 ME: Warm reset req : 0x0 ME: CPU repl valid : 0x1 ME: (Reserved) : 0x0 ME: FW update req : 0x0 ME: (Reserved) : 0x0 ME: Current state : 0x2c ME: Current PM event: 0x0 ME: Progress code : 0x1 ME: Requested BIOS Action: Continue to boot
[...]
PCI: 00:16.0 init ... ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO 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 : Host Communication ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : Host communication established ME: BIOS path: Normal ME: Extend SHA-256: 8c94cd28d87dc681a84d1609b718cb63f2bfd68e5ea89afeccc39e0a559269b2 ME: MBP item header 00020103 ME: MBP item header 00050102 ME: MBP item header 00020501 ME: MBP item header 00020201 ME: MBP item header 00020104 ME: unknown mbp item id 0x104! Skipping ME: MBP item header 02030101 ME: MBP item header 02060301 ME: MBP item header 02090401 ME: mbp read OK after 1 cycles ME: found version 8.1.30.1350 ME Capability: Full Network manageability : enabled ME Capability: Regular Network manageability : disabled ME Capability: Manageability : enabled ME Capability: Small business technology : disabled ME Capability: Level III manageability : disabled ME Capability: IntelR Anti-Theft (AT) : enabled ME Capability: IntelR Capability Licensing Service (CLS) : enabled ME Capability: IntelR Power Sharing Technology (MPC) : enabled ME Capability: ICC Over Clocking : enabled ME Capability: Protected Audio Video Path (PAVP) : enabled ME Capability: IPV6 : enabled ME Capability: KVM Remote Control (KVM) : enabled ME Capability: Outbreak Containment Heuristic (OCH) : disabled ME Capability: Virtual LAN (VLAN) : enabled ME Capability: TLS : enabled ME Capability: Wireless LAN (WLAN) : enabled PCI: 00:16.0 init finished in 6954 usecs
Full cbmem console logs are attached.
Trammell Hudson wrote:
I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary search how much of the firmware it needs...
That would be interesting.
ME: Current Working State : Recovery ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase
..
ME: Current Working State : Reset ME: Current Operation State : Preboot ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : ROM Phase
How do the above change, if at all, with unchanged flash?
With the firmware partition table restored:
..
ME: Current Working State : Normal ME: Current Operation State : Bring up ME: Current Operation Mode : Normal ME: Error Code : No Error ME: Progress Phase : BUP Phase
..
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 : Host Communication
So the ME is clearly in a different state, which is interesting.
But, if your goal is to avoid the ME interfering with the system then I guess there is still some way to go, as long the ME PCI interface works. (Where the above state comes from.)
(Spoiler alert: I don't think it's possible; read the book.)
//Peter
On Mon, Sep 12, 2016 at 09:27:18PM +0000, Peter Stuge wrote:
Trammell Hudson wrote:
I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary search how much of the firmware it needs...
That would be interesting.
After a fairly brief binary search, I have determined a significantly reduced chunk of code required to have the Intel Management Engine bring up the hardware and then stay in the "ROM Phase". This also allowed me to adjust the flash descriptor to give an extra 3 MB of storage to coreboot for my payload, as well as removed some of the problematic ME applications.
The only piece that must be present for my x230 to function is the 512 KB FTPR partition at offset 0x183000, which contains these compressed modules (some Huffman, some LZMA):
'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909
This means that the ME no longer has any network stack (stored in the NFTP partition that has been removed), nor the protected video path or JCOM modules from the MDMV parition. I do not know if the various anti-theft and timeout measures are also now neutralized.
If I leave the firmware partition table at offset 0x3000 in place, the ME faults after bringup (but the system continues to function). Without the partition table it stays in the ROM phase. I'm not sure if one outcome is preferable to the other.
Relocating the FTPR partition did not work unfortunately, so there is some wasted space.
This is fantastic!
I hope you can write this up for the coreboot wiki ...
ron
On Thu, Sep 15, 2016 at 12:24 PM Trammell Hudson hudson@trmm.net wrote:
On Mon, Sep 12, 2016 at 09:27:18PM +0000, Peter Stuge wrote:
Trammell Hudson wrote:
I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary
search
how much of the firmware it needs...
That would be interesting.
After a fairly brief binary search, I have determined a significantly reduced chunk of code required to have the Intel Management Engine bring up the hardware and then stay in the "ROM Phase". This also allowed me to adjust the flash descriptor to give an extra 3 MB of storage to coreboot for my payload, as well as removed some of the problematic ME applications.
The only piece that must be present for my x230 to function is the 512 KB FTPR partition at offset 0x183000, which contains these compressed modules (some Huffman, some LZMA):
'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909This means that the ME no longer has any network stack (stored in the NFTP partition that has been removed), nor the protected video path or JCOM modules from the MDMV parition. I do not know if the various anti-theft and timeout measures are also now neutralized.
If I leave the firmware partition table at offset 0x3000 in place, the ME faults after bringup (but the system continues to function). Without the partition table it stays in the ROM phase. I'm not sure if one outcome is preferable to the other.
Relocating the FTPR partition did not work unfortunately, so there is some wasted space.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Hello Trammel and Coreboot community,
I am following this thread, and thinking... I decided to get involved, but not after carefully thinking about how I can put (some, not all) of my ME knowledge in prospective. Since the area you have touched is very complex, and somehow very peculiar, I should say. I'll let you all judge my answer, and degree of peculiarity. ;-)
Well... Good job, very well done from Trammel's side. I'll try to show two sides of this ME equation: [1] ME functionality. [2] MEI (ME communication component) and HECI (BIOS communication component), two components which from the very existence communicate with each other.
These two sides are inevitable twisted and they are inseparable, considering INTEL philosophy, which follows actually INTEL business model. And Coreboot and Linux are certainly not part of this philosophy, NOT at the beginning, in 80s and 90s of last Century.
So, let us (at first) try to understand the following (by Trammel's investigation):
*"The only piece that must be present for my x230 to function is the 512 KBFTPR partition at offset 0x183000, which contains these compressedmodules (some Huffman, some LZMA): 'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909"*
The accent/stress is on *RED *text. This belongs to Part [2] I already mentioned: MEI and HECI and their communication.
The table presented belongs to part [1]: ME functionality.
Let us look to the following table (courtesy Igor Skochinsky):
[image: Inline image 1]
Link to the very useful presentation (I clipped the above figure): http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
This very closely matches Trammel's investigation... And, to be more punctual, the ONLY access to this area has exclusively ME HW (which is located inside PCH).Tthe CPU itself and BIOS do NOT have access to it.
Essentially, talking about ME, we are talking about the PCH's HW entity, which has the complete CPU inside itself, called ARC (32 bit, not sure if this is a RISC, high probability it is), but ARC HW (driven from inside PCH's embedded FW) accesses from its side flash descriptor, and reads/transfers at one point in time the whole ME partition to the PCH's embedded SRAM). This partition has multiple parts, and one of them is FTPR (kernel in here does mean Threadx RTOS kernel for ARC).
Now, let me try to explain what happens with [2] MEI and HECI communication... Let me repeat: MEI (ME communication component) and HECI (BIOS communication component), two components which from the very existence communicate with each other.
How this communication looks like? Something like this: ME partition gets downloaded to PCH, where it occupies small SRAM area, for the beginning. Then ME initializes Integrated Clock Controller (ICC). Then BIOS starts booting. BIOS thread of execution is the following (the best I could invision from the patchworks reachable to me):
[1] Initializes VGA (via PCIe port);
[2] Initializes Host Embedded Controller I/F init (via HECI PCIe port);
[3] Then BIOS/HECI initiates communication with ME/MEI;
[4] BIOS continues with DDRAMx MRC;
[5] Upon finishing MRC, BIOS/HECI communicates with ME/MEI;
[6] ME starts booting ARC 32bit Threadx RTOS kernel;
[7] ME reserves on the DDRx's TOM (Top Of Memory) 32MB UMA region solely for its own (application) use! _______
Coreboot, upon bringing up, does NOT know about HECI I/F (my best guess) and ME (and MEI). It has no idea that all of this (scary, isn't it) is sitting aside... Actually confirming INTEL HW/FW + WINx SW creation/orientation, warped in late 1990s by Linux influence.
Then, it is easy to imagine that FTPR is THE only ME component, which needs to be executed, since it is essentially part of INTERNAL ME init!
In other words, Coreboot and ME are/must be asynchronous entities (for boot-loader Coreboot use case), which should not know about each other, and ME initially (early stage) controls main CPU solely by HW signals (RESET signals releases), releasing it after it initialized ICC, and after accomplishing transfer of ONLY active FTPR partition to the internal PCH's SRAM. All other ME partitions/components MUST be incapacitated, since they are there serving for/to BIOS/ME interaction and security (my best guess).
This reply is assembled solely from the public net sources (and I sewed lot of details using my INTEL ME knowledge ;-) ), some of which are presented below: http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub https://software.intel.com/en-us/amt-sdk https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface https://software.intel.com/en-us/blogs/2007/01/24/let-us-tal k-about-heci-and-lms _______
Two final considerations here: [1] Hope this will help somehow (expecting comments and discussions)! [2] We can (Coreboot members) continue discussing/writing about ME, trying to do the best to demystify INTEL ME Voodoo Magic! ;-)
Best Regards, Zoran Stojsavljevic _______
On Thu, Sep 15, 2016 at 9:23 PM, Trammell Hudson hudson@trmm.net wrote:
On Mon, Sep 12, 2016 at 09:27:18PM +0000, Peter Stuge wrote:
Trammell Hudson wrote:
I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary
search
how much of the firmware it needs...
That would be interesting.
After a fairly brief binary search, I have determined a significantly reduced chunk of code required to have the Intel Management Engine bring up the hardware and then stay in the "ROM Phase". This also allowed me to adjust the flash descriptor to give an extra 3 MB of storage to coreboot for my payload, as well as removed some of the problematic ME applications.
The only piece that must be present for my x230 to function is the 512 KB FTPR partition at offset 0x183000, which contains these compressed modules (some Huffman, some LZMA):
'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909This means that the ME no longer has any network stack (stored in the NFTP partition that has been removed), nor the protected video path or JCOM modules from the MDMV parition. I do not know if the various anti-theft and timeout measures are also now neutralized.
If I leave the firmware partition table at offset 0x3000 in place, the ME faults after bringup (but the system continues to function). Without the partition table it stays in the ROM phase. I'm not sure if one outcome is preferable to the other.
Relocating the FTPR partition did not work unfortunately, so there is some wasted space.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
On Mon, Sep 12, 2016 at 07:11:41PM +0000, Peter Stuge wrote:
Trammell Hudson wrote:
[...]
What hardware probes would you recommend?
One thing is the LPC bus. It doesn't have that much to do with the ME per se, but I believe it's live from reset and so has early activity.
Another is the boot flash SPI. See what addresses get fetched.
I don't have a concrete tool to recommend, I am developing one, but for the immediate term what you can buy is essentially expensive logic analyzers with LPC and SPI decoders. :\
If you don't need real-time operation, you can use any fast enough logic analyzer and sigrok (http://sigrok.org/wiki/Main_Page). It supports SPI decoding in software.
Regards, Jonathan Neuschäfer
On Mon, Sep 12, 2016 at 11:58:43AM -0600, Trammell Hudson wrote:
On Mon, Sep 12, 2016 at 06:13:16PM +0000, Peter Stuge wrote:
If I just erase the first 4KB of its region (0x3000, starts with "$FPT"), coreboot boots up fine and reports that "WARNING: ME has bad firmware". My Linux payload initializes without any complaints.
Does it stay operational for more than 30 minutes? [...] Does it resume after more than 30 minutes from power-on? And from suspend?
Yes, it has been operational for the past few hours and I'm able to suspend it with 'systemctl suspend' and resume with the lid or power switch. [...]
I wonder if the 30-minute timer is an optional feature. I see that there is an ME configuration variable for "Intel(R) Anti-theft BIOS Recovery Timer" that will "enable a stolen platform a 30 minute window to allow a FW/BIOS reflash before the system is powered down". The Lenovo ME image has this set to false, but perhaps other systems have it set to true or default it to true if the ME flash image is corrupted.
-
Jonathan Neuschäfer -
Peter Stuge -
ron minnich -
Trammell Hudson -
Zoran Stojsavljevic