I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
Will the ethernet controller work?
On Sat, 15 Apr 2017 21:55:52 +0800 persmule persmule@gmail.com wrote:
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
The ethernet controller DOES work. Everything is fine, except the 3~5 minutes first boot, as well as those I reported in the initial email yesterday.
在 2017年04月15日 22:52, Marek Behun 写道:
Will the ethernet controller work?
On Sat, 15 Apr 2017 21:55:52 +0800 persmule persmule@gmail.com wrote:
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
Hello persmule, I am now using coreboot master with ME cleaned to 96 KiB, as you said. There is only one thing: sometimes when booting the kernel prints
kvm: disable TXT in the BIOS or activate TXT before enabling KVM kvm: disabled by bios
I have ENABLE_VMX without SET_VMX_LOCK_BIT, but am using 4.9 kernel (which Paul said has some regressions). Do you also have this problem?
Marek
On Sat, 15 Apr 2017 22:56:31 +0800 persmule persmule@gmail.com wrote:
The ethernet controller DOES work. Everything is fine, except the 3~5 minutes first boot, as well as those I reported in the initial email yesterday.
在 2017年04月15日 22:52, Marek Behun 写道:
Will the ethernet controller work?
On Sat, 15 Apr 2017 21:55:52 +0800 persmule persmule@gmail.com wrote:
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
No. I set both ENABLE_VMX and SET_VMX_LOCK_BIT.
And there is no weird reports from kvm.
Persmule
在 2017年04月16日 20:27, Marek Behun 写道:
Hello persmule, I am now using coreboot master with ME cleaned to 96 KiB, as you said. There is only one thing: sometimes when booting the kernel prints
kvm: disable TXT in the BIOS or activate TXT before enabling KVM kvm: disabled by bios
I have ENABLE_VMX without SET_VMX_LOCK_BIT, but am using 4.9 kernel (which Paul said has some regressions). Do you also have this problem?
Marek
On Sat, 15 Apr 2017 22:56:31 +0800 persmule persmule@gmail.com wrote:
The ethernet controller DOES work. Everything is fine, except the 3~5 minutes first boot, as well as those I reported in the initial email yesterday.
在 2017年04月15日 22:52, Marek Behun 写道:
Will the ethernet controller work?
On Sat, 15 Apr 2017 21:55:52 +0800 persmule persmule@gmail.com wrote:
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
So apparently disabling building relocatable kernel fixed the issue with kvm.
But I have now a different issue which renders my X230 useless with completely stripped ME. It seems that native ram init does not work completely correctly with my RAM modules, or something. When using coreboot-master with cleaned ME, at random times applications crash with something like BUG: stack guard page was hit at ffff990102a7c000 (stack is ffff990102a78000..ffff990102a7bfff) or the system completely freezes. This has more probability of happening when the CPU is loaded.
I have two 8 GiB ram modules: Samsung M471B1G73BH0-CK0 12800S-11-11-F3 Elpida EBJ81UG8BBU0-GN-F 12800S-11-10-F3
They have slightly different parameter (11 vs 10). Could this be the problem?
I have also tried removing one module, but than the first boot (generation of mrc cache) was taking too long (I stopped it at 10 minutes).
Any ideas?
Thanks.
Marek
On Sun, 16 Apr 2017 20:34:03 +0800 persmule persmule@gmail.com wrote:
No. I set both ENABLE_VMX and SET_VMX_LOCK_BIT.
And there is no weird reports from kvm.
Persmule
在 2017年04月16日 20:27, Marek Behun 写道:
Hello persmule, I am now using coreboot master with ME cleaned to 96 KiB, as you said. There is only one thing: sometimes when booting the kernel prints
kvm: disable TXT in the BIOS or activate TXT before enabling KVM kvm: disabled by bios
I have ENABLE_VMX without SET_VMX_LOCK_BIT, but am using 4.9 kernel (which Paul said has some regressions). Do you also have this problem?
Marek
On Sat, 15 Apr 2017 22:56:31 +0800 persmule persmule@gmail.com wrote:
The ethernet controller DOES work. Everything is fine, except the 3~5 minutes first boot, as well as those I reported in the initial email yesterday.
在 2017年04月15日 22:52, Marek Behun 写道:
Will the ethernet controller work?
On Sat, 15 Apr 2017 21:55:52 +0800 persmule persmule@gmail.com wrote:
Hi Marek,
You should use the latest me_cleaner. The 96 KiB ME actually works, but just costs about 3~5 minutes to training the memory controller and write MRC cache during the first boot after flashing, and costs less than one second during later boots.
The only ME modules needed left should be BUP nad ROMP, all other modules are free to cleanse.
Try again, please, for your own freedom and security, and report your results on https://github.com/corna/me_cleaner/issues/3
Persmule.
在 2017年04月15日 20:13, Marek Behun 写道:
I have just now managed to flash my X230 with ME truncated to 828 KiB. I used an older version of me_cleaner (commit d1abbca2). This is because the current version of me_cleaner (which truncates ME to 96 KiB) does not work for me (X230 won't boot).
The currently active modules in my ME are (listed with unhuffme): BUP CLS ClsPriv FTCS HOSTCOMM KERNEL POLICY ROMP RSA SESSMGR TDT UPDATE
Note that originally ME contained all this modules: admin_cm BOP BUP CLS ClsPriv CONF_STACK eac FTCS HOSTCOMM ICC JOM KERNEL krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM POLICY ROMP RSA sal secio SESSMGR TDT tls UPDATE utilities WCOD_PUMA wlan
So the remove modules are: admin_cm BUP CONF_STACK eac ICC JOM krb LOCL_GER MPC NET_SERVICES NET_STACK NFC Pavp PLDM sal secio tls utilities WCOD_PUMA wlan
I do not know what all can the modules that I left there do, but my e1000e is working.
The current layout of the flash is:
00000000:00000fff fd 000d2000:00bfffff bios 00003000:000d1fff me 00001000:00002fff gbe
This left me with 10.85 MiB for the payload.
I am attaching my current descriptor.bin and me.bin, if someone wants to try.
Marek
Hi Marek,
On 17.04.2017 02:28, Marek Behun wrote:
So apparently disabling building relocatable kernel fixed the issue with kvm.
that seems pretty random.
But I have now a different issue which renders my X230 useless with completely stripped ME. It seems that native ram init does not work completely correctly with my RAM modules, or something. When using coreboot-master with cleaned ME, at random times applications crash with something like BUG: stack guard page was hit at ffff990102a7c000 (stack is ffff990102a78000..ffff990102a7bfff) or the system completely freezes. This has more probability of happening when the CPU is loaded.
I have two 8 GiB ram modules: Samsung M471B1G73BH0-CK0 12800S-11-11-F3 Elpida EBJ81UG8BBU0-GN-F 12800S-11-10-F3
PC3-12800 is most common...
They have slightly different parameter (11 vs 10). Could this be the problem?
Unlikely.
I have also tried removing one module, but than the first boot (generation of mrc cache) was taking too long (I stopped it at 10 minutes).
Any ideas?
Modding the ME firmware is about freedom. The freedom to work around issues you won't ever see otherwise ;)
What you describe sounds much like random instability (which I'd expect if RAM training takes that long). Either the system is just unstable (who knows which fixes you miss if you drop the ME firmware (update)) or something related to the memory controller is off. I have a vague theory: The ME firmware is sometimes referred to in clock generation context. Maybe the memory clock is just not the one coreboot thinks it has configured.
I would try the following to narrow it down: Run the memory training with the original ME firmware; keep the MRC cache intact while switching to the truncated ME firmware; boot. If it doesn't work with the cached values, something around the memory clock might be off. If you have de- bug access, you could also directly compare the training results from a boot with the original ME firmware vs. the modded firmware. If not you can still compare the results from MRC-cache dumps. But you'd have to decode them first...
Nico
I would try the following to narrow it down: Run the memory training with the original ME firmware; keep the MRC cache intact while switching to the truncated ME firmware; boot. If it doesn't work with the cached values, something around the memory clock might be off. If you have de- bug access, you could also directly compare the training results from a boot with the original ME firmware vs. the modded firmware. If not you can still compare the results from MRC-cache dumps. But you'd have to decode them first...
So I tried to put mrc.cache generated with ME into CBFS, but after reboot, mrc cache was regenerated. I investigated, and found out: 1) in mrc.cache with ME, the data begins 4 bytes sooner than in mrc.cache without ME. This could be the reason why mrc.cache was regenerated: the one that was found there (generated by coreboot with ME) was invalid for coreboot without ME? 2) there are different timings in the cache generated without ME. I have written an utility to print the data stored there. I am attaching those two together with a diff.
I am going to try to somehow change the mrc.cache generated by coreboot with ME so that coreboot without ME accepts it as valid and does not regenerate.
Marek
- there are different timings in the cache generated without ME. I have written an utility to print the data stored there. I am attaching those two together with a diff.
Forgot to attach, attaching now.
Marek
-
Marek Behun -
Nico Huber -
persmule