Software ME disable and HAP bit in BIOS setup #111
Comments
|
I'm very interested in this feature for the Z690 board. If it is easier in terms of development, I think most people who want this feature are fine HAP being set in the bin file, and you need to flash the ME section to enable or disable ME. |
|
Dasharo users should know the difference between Intel ME disabled state and neutralised ME. We receive quite a lot of demands if we can neutralise Intel ME (which is not possible (yet)). If anyone reads this and believe that this is an important function for the future, please comment! |
|
I think being able to neutralize the Intel ME backdoor is of great importance. What has to be done in order to move forward regarding this task? |
|
I'd like to comment that I think it certainly be a very important function for Dasharo to either neutralise or at least disable Intel ME. Intel ME is an obscure system that has privileged access and thus presents very grave security and privacy issues. I pay Intel for their chips, but I don't want that to come with potential backdoors into my computer! |
|
Looks like somebody discovered the HAP location for newer ME versions: corna/me_cleaner#384 |
|
Did a quick test on NovaCustom NV4x with Dasharo v1.2.1, and it seems to work correctly. As expeted with TGL-U, disabling ME breaks suspend mode (prevents the CPU package from going into C-state C10, causing high power usage), but I imagine some users would accept that as a tradeoff As for Z690, unfortunately that PR does not implement Alder Lake support. |
|
Yes, it doesn't work with the Z690 / ME v16 I tried it on the Z690 dump, and it just fails while processing the rom |
|
If you're ready to make some tests and not afraid to potentially (very low risk I believe) damage your motherboard (flashing externally is crucial in case it doesn't boot), I can try to find the HAP bit for Intel ME 16 and add support to me_cleaner if you send me your BIOS, we can maybe figure this out. We can talk about this in XMPP, IRC or anything. |
|
You can download my rom here https://drive.proton.me/urls/TJTSPK5960#8asKbIr7icmg The external programming is a bit more difficult, I have a handheld wson test probe, but I need to completely disassemble my desktop PC to use it. |
I see, sadly you would need to probably flash it around 10-20 times to be sure it's working. Though once it's done, I'll send you a new BIOS ROM to test with, the idea to find it will be mostly simple if I'm allowed to say it legally, but I tested this method on my laptop before and it worked. The problem will be later to find the real HAP bit location, which will need probably around 7-8 flashes, depends really on the location of the HAP bit offset so it can be used with me_cleaner this way. |
|
This may work, if it doesn't or it doesn't boot, let me know, I'll try something different. https://xutaxkamay.com/bios_test_hap.rom Using XMPP (you can use Dino or Gajim) might be easier you can contact me at admin@xutaxkamay.com |
|
I assume I only need to flash the ifd section of the rom?, not having to flash the full 32 MB image would make it a lot easier. I can try to flash it tomorrow when I get home from work. |
Yes you only need to flash the IFD region (0x1000 bytes at address 0). :) I believe to have found for Intel ME 16, redownload the BIOS again, and tell me if it works. |
|
I wasn't able to read the ifd with the eprom programmer I have, which makes not want to try and flash the firmware, at least not until I found some way to recover in case it fails. I'm pretty sure flipping 0x1DE has already been tested, and it results in a boot loop. The official flashrom says the ifd is skylake and 17mhz is the only valid frequency, and the dasharo flashrom doesn't support the ch341a_spi programmer I'm using. |
That's not what causes the boot loop I think, the boot loop is a different problem as dt-zero said on my pull request here: corna/me_cleaner#384 (comment) Basically your BIOS could have been signed and that's why it could boot loop. If you can't externally program, there's indeed no safe way to do it. Sorry to say. |
|
This guy tried 0x1DE with the stock msi firmware corna/me_cleaner#282 (comment) But you could be right, and it could possibly work with coreboot firmware, but I do think this is a big maybe. It did make me wonder if the stock firmware has some recovery option, it at least didn't seem like he bricked his motherboard and was able to just reflash the stock firmware. |
I didn't know it was found before, but if it boot loops, If it just doesn't boot at all then yes in that case it might be the wrong offset and this is possible according to my research due to different chipsets or ME subversions apparently. Usually desktop motherboards have a pin header which connects to SPI flash chip so that you can connect with a raspberrypi or something similar, it is probably not documented but it should be visible. EDIT: |
|
The Dasharo documentation explains how to connect to the flash using the pins on the motherboard, but for it to work, you need to solder a wire to pin 1 on the flash. I would prefer not having to solder the wire to the motherboard, the chip is the wson https://docs.dasharo.com/variants/msi_z690/development/#hardware-connection There is also no way to know if a raspberry pie is going to have the same issue as the ch341a. I did try using the latest git version of flashrom, it gave me the same error. The Dasharo documentation says you need to define the spi speed when using an external programmer, I'll try that today and see if it makes a difference. |
|
Is it a WSON-8 BIOS chip? I successfully flashed one of our laptops with such a BIOS chip without soldering by using this clip and the ch341a programmer. https://www.aliexpress.com/item/1005001830846980.html?spm=a2g0o.order_list.0.0.7fd91802wpld5n (Version WSON 8x6 strengthen) But I am not sure if that motherboard has a WSON-8 BIOS chip. Also, I am not sure if the particular BIOS chip is supported by flashrom. |
|
I'm using a similar test probe, and flashrom detects the chip. It says the chip type is experimental, but it seems to work. My main issue is that hold the probe by hand for the full 32 MB flash is extremely difficult, for any chance of this to work I would need to fully disassemble the desktop system and take out the motherboard, and even then it would be difficult to hold the probe perfectly still for the full duration. Flashing an 8 MB chip with the probe often takes me more than one try, but 32 MB make it exponentially more difficult to hold the probe for that long. I was testing the ch341a with --ifd, and it was given me a warning that it couldn't read ifd. If I can read ifd I was hoping I would do something --ifd -i ifd to only flash the ifd region. When I use --ifd it just says the chip looks like skylake, but it can't read the ifd at 17mhz, and that 17mhz is the only valid setting for skylake. |
|
I believe it's difficult because there are no 'pins' that keep the programmer clip on the right place? With the clip I mentioned, I added another retaining clip and put something that weights a bit on that so that I didn't need to hold the clip with my hand. Admittedly, it was a pain to get it on the exact right place but it's feasible. If you would like, I can try again and send you a picture. |
|
I got it working, I was using --ifd -i ifd and not -i fd Now I can read and write only the fd region without any issue. I tried flipping 0x1DE, it seems to work, I can't see mei is /sys/class or with lsmod I'll leave the system running for 30 min to see if the CPU locks. |
|
. . . xD Well let me know. It sounds good though. |
|
This is from my initial test running Linux/Ubuntu, the CPU didn't lock and mei is removed In Qubes OS, I have iwlmei that is trying to use mei, but there is no device reference i /sys/class/mei and the onboard wifi is no longer working. I personally don't use the onboard wifi, so I don't are about that issue, and everything else seems to be working. |
|
Looks good! I hope it is stable! |
|
@renehoj Just to confirm, you are succeeding with flipping that 0x1DE bit on coreboot? Not OEM firmware? I'm starting to lean on the side of this "boot loop" thing some people are experiencing is probably the result of some new validation in the OEM firmware. I don't necessarily mean the capsule signing, as that should not affect the PCH strap region where the HAP bit is located, but some other interaction from a UEFI driver. |
|
I have only tested with Dasharo/coreboot v1.0.0, I have not tested the MSI firmware, and I used an external programmer til update the fd region. I don't know if it matters, but maybe the person who flashed the OEM firmware used the manufacture's tools to write the rom, maybe it doesn't work if you manipulate the bin file. |
|
If you have an external programmer in case of a brick, you should be fine in most cases. For the soft-disable and HAP, try to use MEInfo (Intel System Tools) that you can get here: https://winraid.level1techs.com/c/special-topics/intel-management-engine/24 and run ./MEInfo -FWSTS On HAP, you should get either "Disabled" or "Alt Disabled" being prompted somewhere, or having an error that it can't find the MEI driver or something similar (Intel ME Interface should not be present anymore). On soft-disable, you should get "Temporarily Disabled" if my memories are correct. |
|
@phodina thanks for joining group of brave people that flashed Dasharo. As always we are very interested know use cases of our community members to push project in correct direction. So what brought you to Dasharo and dealing with ME? Do you have specific use case or workload ? What other features would be most wanted features for you? |
I'm familiar with this tool. Is the one you suggest tool for Windows? |
|
Thanks for amazing work! Well as stated above I design systems with Linux and Trust Zone on ARM boards and use GNU Guix as operating system to build everything from scratch + some nonGNU parts for firmware :-D to have working machine but trying to keep it to minimum. In past I was proud owner of x230 where I used the Pomona clip to modify the SPI Flash. Unfortunately the machine is now in silicone heaven and for today usage it's little bit under-powered. So I looked for some recent x86_64 machine with coreboot support and preferably ME neutralized - found your work. I strongly believe you should own the stuff if you buy it and be in charge what the device does. It shouldn't be a black box. You shouldn't have the option to disable this ME. It should be disabled by default and you should be able to opt-in not vice versa. Also compare to other architectures e.g. ARM and MIPS, x86/x86_64 is really a black box and not much documented - true ARM is documented by vendors, DDR training is usually proprietary as well and there isn't any standard just mess. But you have to option to take ownership of the whole platform. Well except for the ISA and hardware itself. The former is solved by RISC-V. The latter I don't know as verifying HW on the Silicone level is far more challenging (e.g. if it doesn't have some special HW backdoor circuitry). Well but there is hope with you guys, team from Purism, projects like Postmarket OS that liberates the mobile phone landscapes and RISC-V (projects like Precursor). To your other question the features I'd like to see are similar as the PureOS tamper detection on more platforms. The other feature would be to have it distributed as a part of LVFS so that the BIOS is updated on the background and always up to date. Both things might make it interesting from company point of view in order to ditch vendors that don't support transparency - not it's hard to even open this topic as this market does not exist and DIY approach does not solve it. The wish for the future would be that having Coreboot on the motherboard as BIOS is standard this and you get it preinstalled by default. So that you don't have to do the impossible work just the modifications you/customer needs. Sorry for off-topic post :-) Edit: Forgot why I wrote the post. It boils down to reproducibility and firmware is big part of the picture. |
Sorry, I should have said Intel's System Tools, they're basically user-space tools that are made by Intel which communicates with the Intel Management Engine Interface (PCI device). They are usually shared among BIOS/ME updates officially by motherboard manufacturers or leaks. And yes / no, Intel ME can be "software disabled" from user-space by asking to the Intel Management Engine Interface (previously called HECI) to soft-disable (Temporarily Disable) with the Flash Programming Tool that Intel provides. The "HAP" is basically a superior version of software disabling Intel ME, not turning off really to be clear but enough so that we hope it does nothing after hardware initialization, I suggest reading ptsecurity blog for more deeper explanation here as it helped me to discover others possible offsets: https://www.ptsecurity.com/ww-en/analytics/disabling-intel-me-11-via-undocumented-mode. There is basically two versions of these tools, Consumer or Corporate. If you got the Consumer version you can soft-disable like so with the Flash Programming Tool (FPT): If you got the Corporate tools, there's actually hidden argument called "MEALTDISABLE" which can be called like so: Where 0 enable only HAP, and 1 & 2 does a bit more than just enabling HAP. The second argument with > 0 seems to be used for an enhanced version of HAP, but I'm not sure yet, and it's true that I've been lazy to discover what those does really, but I'll get here eventually. Now, technically, EDIT: The reason why we would keep it as an option, as Dasharo team said here #111 (comment), it breaks S0ix and yes I love Dasharo's work EDITEDIT: And right it could be great to have a feature to check the integrity of the BIOS without relying on Intel BootGuard or TXT. For an easy solution, guess it could be done by just having an external USB that have a distro that reads the BIOS and check the checksum with self-integrity mechanisms to be sure that the BIOS somehow didn't overwrote some opcodes or have backdoors in EFI Runtime Services, stuffs like that. (unlikely, but you never know) Perhaps, maybe re-soldering the BIOP chip with another write-once (and turns off read) chip to avoid external programmers, and restrict the access to coreboot tables would be enough. I know manufacturers like Microchip tend to have such protections, but yeah never tried on that road yet, would need to search a compatible chip and such. EDITEDITEDIT: Also I got a better look on the TPM security that Purism provide; I see this: "The next time the system boots, measurements from every executable part of the boot process is sent by Heads to the TPM and stored in PCRs." Maybe sorry for my lack of knowledge, but isn't that risky? Doesn't that mean that I could just overwrite some opcodes in Heads and instead of sending the whole BIOS as it is, I could send the non-tampered BIOS (could be compressed somewhere to save some bytes) to the TPM ? I believe it should be the TPM reading directly the BIOS chip instead ? |
|
@phodina thank you for your feedback. We really appreciate it. To comment on some:
Did you heard about Fobnail ?
I'm not sure if we will invest in integration with LVFS, key question is also if MSI would like to see ability to switch to open-source firmware in Linux Foundation project. I don't know about public statement from LVFS if they will allow such feature. But if we talking about We plan to use that feature to enable subscription-based updates (Supporters Entrance) and some additional features. This is because we have to make whole Dasharo project sustainable. BTW I wonder what would be your opinion about paying for updates and additional features.
It means we have to be serious enough to convince major hardware vendor. I believe this is possible, but not as coreboot project, that's why we created Dasharo open-source firmware distribution.
Agree. We hope to have part of our Dasharo Certification Program responsible for proving that and providing grading. I guess this can be connected with Dasharo Openness Score and SBOM. |
|
@XutaxKamay I guess some of your ME-related writing could be used to improve Dasharo Documentation if you are ok with that.
We work on open TPM, TwPM (Trustworthy Platform Module), former lpnTPM
Connecting external SPI chip (e.g. Framework modular design) and/or fusing board to your public key? We would love to support IBG open manner assuming multiple slots are available for ownership transfer. Of course this lead to trustworthy ownership transfer procedures - probably best model was presented publicly by IBM as part of OCP effort.
Any measurement in measured boot is as good as protection of code that does initial measurement. In case of devices shipping with Heads the problem is that in most cases that we know bootblock is not protected. So if you compromise bootblock you can fake next stages and unlock secret by replying hashes extended into TPM PCRs.
Question is how about first executable part.
If you replace Heads it will have different measurement in PCR, what can be detected. What you have to do is going to the lowest possible layer which is bootblock.
TPM is to simple for that. Please check D-RTM and TrenchBoot which is closer to executing in protected enclave and making PCR extend operation by pure hardware. |
Sure, I would be glad if it becomes useful.
Didn't know about that, thank you for your work on that.
This could be awesome actually if we could plug a chip (like an interporser) just like any other main components like RAM and such.
Right if you have coreboot and modify the bootblock (1st stage), then you can possibly compromise everything else as I'm looking right now since the bootblock is responsible for sending the hashes to the PCRs, which is called SRTM apparently. Thanks for the clarification. :)
Right I know it is used only for storing keys and such, and definitely not for reading the BIOS, but perhaps maybe something like you said with fusing board with your public key and using a crypto-processor that checks the BIOS signature with your public key or/and checksum. right DRTM; that's what I probably meant then by Intel TXT and BootGuard (since it is used to fuse OEM keys for ACMs to check the integrity of the whole UEFI firmware apparently), I have heard once about TrenchBoot but I never really looked at it, thanks again the replies, it did gave me some clarification on some of my doubts. |
I haven't heard. Thanks for the link!
Well It's up to MSI, that's in their hands. Having a non-LVFS server is good approach for the deployment and basically answers the question.
That's a good idea. I understand that the development and maintenance cost something. Regarding the subscription I think it's good approach. Especially if you can also provide some support and testing of the firmware as this is impossible to do at home. 60 Euro per year seems as good balance.
Agreed that you need to be a company in order to one day see coreboot on the motherboard.
Very nice analysis and job done opening the BIOS! |
|
I have tested v1.1.0 with HAP on my system, and everything seems to be working. Reboot and Wi-Fi didn't work before, and they both work now. |
|
Yes, we should. |
|
Nice. I move this issue to column DONE. |
|
Is it possible to implement this feature for our NovaCustom-Dasharo devices? |
|
@wessel-novacustom yes, it definitely is. Although some drawbacks will be probably inevitable (we saw HAP breaks the sleep functionality). |
|
Cool, definitely as a BIOS option! :-) I'll discuss the matter with @macpijan in our meeting tomorrow. For those who follow this post, I will leave an update here. |
@wessel-novacustom Any update? |
|
@davidhealey Our developer's are still working on this. An update is expected in February. Let's hope no stability issues will be found, we will have to test this extensively this month. |
Good morning. |
|
Good morning @sateuwdie , we have integrated the ME disable option into the Alder Lake laptop line, however we are struggling with different issues that delay our release at the moment. |
|
Thanks for answer, I have a i7-1260P. is Alder Lake? |
|
@sateuwdie yes, it is Alder Lake -P processor for mobile devices, also used in Novacsutom laptops. |
|
Thanks for answer, I will wait for the new bios release. |
Will this feature be possible in the Tiger Lake laptops also? |
Yes it is possible. However, we did not integrate it yet into TGL series. |
|
Do you plan on integrating it in the future? |
|
It is not on the priority list right now, but we might put it on the roadmap with @wessel-novacustom after we deal with the more urgent problems. |
|
We would need to know how many users are interested in this for our TGL devices. The effort (and thus the costs) are quite high, so it's only feasible if we have enough feedback of NovaCustom TGL device owners who want to have this feature. |
The problem you're addressing (if any)
Proprietary components are controversial, there is a need for a way to disable ME.
Describe the solution you'd like
Add an option to disable ME in the Dasharo setup.
Where is the value to a user, and who might that user be?
The community desires an option to disable ME due to privacy concerns and not only that.
Describe alternatives you've considered
None
Additional context
None
The text was updated successfully, but these errors were encountered: