search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.41k stars 183 forks source link

Provide IFD, Gbe and ME blobs #307

Closed osresearch closed 3 years ago

osresearch commented 6 years ago

The 12 MB x230 ROM image isn't flashable since it doesn't include the IFD and ME sections. This isn't normally a large problem for updates since flashrom-x230 won't touch the ME region, but it does lead to problems for initial install.

tlaurion hijacking top post here to give actual status in a glimpse.

Mitigations from dropping those binaries would be to:

So the result of the ongoing #703 PR is a PoC of that, which requires Heads to fake MAC address on boot to not have a MAC collision on the same LAN network segment if many Heads xx30 empowered machines are present.

Todo:

MrChromebox commented 4 years ago

@tlaurion can't the IFD be extracted from the FL1 via g2uj31us.exe ?

tlaurion commented 4 years ago

@MrChromebox haven't found a way to have a workable 8mb image to apply me_cleaner on, following precedent recipe and tickets open at chipsec and uefi-firmware-parser

n4ru commented 4 years ago

Extracting from a full ROM is easy, but I thought the point was to get rid of the requirement?

tlaurion commented 4 years ago

@n4ru : Extracting full rom from update files (FL1 FL2) would fill the requirement to be able to regenerate IFD and neuter+deactivate+shrink ME in one pass.

May misunderstand what is the easiest here, but I would have thought that 8Mb and 4Mb SPI rom images could be extracted from FL1/FL2, but it doesn't seem so. If so, applying me_cleaner on the 8mb ROM extracted from FL1/FL2 would permit what I try to accomplish here.

tlaurion commented 4 years ago

@n4ru: As of right now, me.bin is consistent and extracted directly from your provided link. That can and will be scripted in a submodule. The question is if the current approach is enough to negate any legal implications, and to be sure, ifd should also be extracted as an equivalent of what is to be provided here: unlocked, with AltME bit set and regions being RW.

But that ifd.bin still comes from a externally backuped flashed rom. Cannot be done by script from original Lenovo provided exe right now. That is desirable.

If you have any inputs, that would be awesome, else @osresearch stated here that he was not disagreeing to have ifd.bin provided in the repo.

@MrChromebox @merge @n4ru: Not having any of those blobs in the repo and extracted on first CI run would be of course more desirable.

tlaurion commented 4 years ago

@MrChromebox

can't the IFD be extracted from the FL1 via g2uj31us.exe ?

how?

MrChromebox commented 4 years ago

@tlaurion I was under the impression that the FL1 was a full flash image, is it not?

PatrickRudolph commented 4 years ago

@tlaurion can't the IFD be extracted from the FL1 via g2uj31us.exe ?

No as it doesn't contain IFD or ME. It looks like an UEFI update capsule. You can use the UEFITool to open it and see it's contents.

The FL2 seems to be an EC update only.

Maybe other update files contain a ME, not sure about the IFD.

PatrickRudolph commented 4 years ago

There's no need to use a Lenovo BIOS for this, any BIOS update from any vendor for the same PCH which contains a full ROM will do.

n4ru commented 4 years ago

There's no need to use a Lenovo BIOS for this, any BIOS update from any vendor for the same PCH which contains a full ROM will do.

Incorrect, as we've already surmised there are no BIOS updates with a "full ROM" and other vendors have no reason to contain identical blobs.

FL1 contains the BIOS module. FL2 contains the EC module. ME installer contains the ME production binary, but not the entire UEFI module. This may be enough. IFD and GbE still missing.

ThePlexus commented 4 years ago

Ive been struggling for a way to get around having to use the Phoenix rescue e_bcpvpw.exe for quite some time. For x230, can the bios be extracted from FL1 in the same way coreboot used to extract the VGAbios from same using UEFItool? https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios

For the desktop board Ive been dabbling with ( see #550 ) ive scripted up something which grabs the vendors bios, validates the hash, ME neuters it, modifies it to 8mb size, drops the VSCC (per [https://github.com/corna/me_cleaner/issues/80] ) and then splits out the IFD and ME ROM files out ready for the coreboot build. Luckily ASUS isnt so convoluted as lenovo in their bios distribution files.

In light of that, what would be the correct way to do script this for this desktop board in the build process. Something in /modules was where i was thinking? It requires IFDtool, so i guess its going to be a 2 part process - part 1 to grab the vendor ROM and then validate hash (at the same time that the rest of the required modules are grabbed and validated). Obviously only when BOARD=p8h61-m_pro is selected. Then part 2 when me_cleaner and ifdtool are present in the coreboot build (which also has to be before coreboot ROM is built, given im going to use the IFD and ME ROMs it outputs). I can just hack something together and make it work(tm) but i really would love to hear advice on best places, timings and methodology to run the parts from.

tlaurion commented 4 years ago

Everyone, I'll propose a x230-external-flash blob directory PR on which a new x230-external-flash board will depend.

Will need other testers to test it with their xx30 boards. This absence of movement is driving me crazy.

eganonoa commented 4 years ago

response_container_BBPPID{font-family: initial; font-size:initial; color: initial;} Happy to test x230 with key. Sent from my BlackBerry — the most secure mobile device From: notifications@github.comSent: 12 April 2020 17:24To: heads@noreply.github.comReply to: reply@reply.github.comCc: ralphbunche@gmail.com; comment@noreply.github.comSubject: Re: [osresearch/heads] Provide IFD and ME blobs (#307)

Everyone, I'll propose a xx30 blob directory on which a new x230-hotp board can depend. Will need other testers to test it with their xx30 boards. This absence of movement is driving me crazy.

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

tlaurion commented 4 years ago

response_container_BBPPID{font-family: initial; font-size:initial; color: initial;} Happy to test x230 with key. Sent from my BlackBerry — the most secure mobile device From: notifications@github.comSent: 12 April 2020 17:24To: heads@noreply.github.comReply to: reply@reply.github.comCc: ralphbunche@gmail.com; comment@noreply.github.comSubject: Re: [osresearch/heads] Provide IFD and ME blobs (#307) Everyone, I'll propose a xx30 blob directory on which a new x230-hotp board can depend. Will need other testers to test it with their xx30 boards. This absence of movement is driving me crazy. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

@eganonoa : you have a xx30 based board? Here states you have a x220 only (xx20 board)?

eganonoa commented 4 years ago

Yep have an x230, also with heads and hotp with the librem key. Actually have many as have moved my whole (small) org to them, with a couple spares.

On Sun, Apr 12, 2020 at 10:54 am, tlaurion notifications@github.com wrote:

response_container_BBPPID{font-family: initial; font-size:initial;

color: initial;} Happy to test x230 with key. Sent from my BlackBerry — the most secure mobile device From: notifications@github.comSent mailto:notifications@github.comSent: 12 April 2020 17:24To: heads@noreply.github.comReply mailto:heads@noreply.github.comReply to: reply@reply.github.comCc mailto:reply@reply.github.comCc: ralphbunche@gmail.com mailto:ralphbunche@gmail.com; comment@noreply.github.comSubject mailto:comment@noreply.github.comSubject: Re: [osresearch/heads] Provide IFD and ME blobs (#307 https://github.com/osresearch/heads/issues/307) Everyone, I'll propose a xx30 blob directory on which a new x230-hotp board can depend. Will need other testers to test it with their xx30 boards. This absence of movement is driving me crazy. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

@eganonoa https://github.com/eganonoa : you have a xx30 based board? Here https://github.com/osresearch/heads/issues/692#issue-577966678 states you have a x220 only (xx20 board)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/osresearch/heads/issues/307#issuecomment-612652912, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANQ47E5R5MLBRS57WKLBKLDRMH57FANCNFSM4EPUHVAQ.

tlaurion commented 4 years ago

@tlaurion so you're proposing to put the blobs in the main Heads repo, along with reproducibility instructions? Any reason to not put them in a submodule as was discussed previously?

@MrChromebox : Any idea how to use innoextract to extract exe content (cab) in a module?

MrChromebox commented 4 years ago

@tlaurion I'd have to look into it, I've never used it myself

tlaurion commented 4 years ago

@MrChromebox : meanwhile, considering we have +1 here: https://github.com/osresearch/heads/issues/307#issuecomment-588365157 https://github.com/osresearch/heads/issues/307#issuecomment-591336428 https://github.com/osresearch/heads/issues/307#issuecomment-596813784

And nothing is put against https://github.com/osresearch/heads/pull/703 I would appreciate a +1 in the PR so I can merge.

tlaurion commented 4 years ago

@osresearch @merge @MrChromebox @SebastianMcMillan @n4ru @kakaroto @kylerankin @jans23 @szszszsz @patrickrudolph:

Finally a legal answer from FSFE. Insights, contacts, to make this go forward?

...if the binary blob contains copyrightable material, it would be a copyright infringement to make it publicly available without the permission of the copyright holder.

Assuming that the blob does indeed contain copyrightable material, you have three options available:

1) Ask the copyright holder for a license This is the best option (because others can to refer to this license as well) but there might be problems for Lenovo to do so (e.g. unclear copyright situation, unclear internal situation to make such a decision, unwillingness to license binaries without source).

2) Ask the copyright holder for permission to make it available as the project wants to do it. It could be easier for Lenovo to agree upon because they can withdraw the permission at any time.

3) Writing to the copyright holder that the project assumes consent if there is no explicit statement otherwise. This is legally incorrect, and Lenovo might take legal action in such a situation. Nevertheless, this could improve the legal situation. If you have already written to Lenovo and not had any response, you could simply send another email that notifies them as such, putting the ball in their court. If it can be shown that Lenovo had knowledge about the fact that the binary blob is publicly available for a long time, forfeiture could apply.

Unfortunately, the FSFE does not have any contacts from Lenovo within our Legal Network. Nevertheless, we have reached out to our contacts at Intel to see if there's anything that they can do.

tlaurion commented 4 years ago

@PatrickRudolph : Contacts at Lenovo?

siro20 commented 4 years ago

No, sadly not. Usually nobody feels responsible for the old products they don't maintain any more. So this could be a difficult task.

tlaurion commented 4 years ago

Following #700 conclusions, without gbe blob, no ethernet.

MrChromebox commented 4 years ago

the GBE blob is necessarily system unique though, right? since it contains the MAC address?

tlaurion commented 4 years ago

(EDIT) Tracking of attempts:

Thrilleratplay commented 4 years ago

@MrChromebox @tlaurion I came here via the me_cleaner ticket opened. There is a lot going on between a number of repos and tickets but did want to mention something relevant to the gbe blob.

Yes, the gbe blob from the x230 contains the mac address. Using hexyl on the gbe blob outputted from iftool , the address is at offset 00000000 and 00001000. Something I wanted to test was to modify the mac in the firmware and see if it still worked, like a low level mac spoofing. Also, quite a bit of the blob looks like it is padding and wondered how difficult it would be to reverse engineer the remainder.

EDIT: Oops, looks like I a little slow. @tlaurion seemed to have figured this out in #700

tlaurion commented 4 years ago

@Thrilleratplay : no its not fixed (not randomized). Its the actual mac address provided in gbe.bin blob that is exposed and present directly in the blob in that issue update, showing its addresses. I haven't tried to randomize it yet. Any success on your side?

Thrilleratplay commented 4 years ago

@tlaurion I'm sorry I don't understand what you mean by

no its not fixed (not randomized)

The MAC addresses seems to be in a fixed position at those hex offsets. My offsets match the ones you posted in #700 and they are also the same on my x220. I haven't tried modifying the addresses, I assumed there was a crc32 checksum or something that verified the mac's validity apart from the vendor prefix.

tlaurion commented 4 years ago

I meant I didnt try to modify it.

On May 12, 2020 10:20:06 PM UTC, Tom Hiller notifications@github.com wrote:

@tlaurion I'm sorry I don't understand what you mean by

no its not fixed (not randomized)

The MAC addresses seems to be in a fixed position at those hex offsets. My offsets match the ones you posted in #700 and they are also the same on my x220. I haven't tried modifying the addresses, I assumed there was a crc32 checksum or something that verified the mac's validity apart from the vendor prefix.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/307#issuecomment-627629359 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

tlaurion commented 4 years ago

GBe attempts can be followed here

tlaurion commented 4 years ago

on IGB: missed that and looking at it https://libreboot.org/docs/gnulinux/grub_cbfs.html#changeMAC

tlaurion commented 4 years ago

@MrChromebox @PatrickRudolph

the GBE blob is necessarily system unique though, right? since it contains the MAC address?

Well, Leah seems to have resolved that 2 years ago: https://notabug.org/libreboot/libreboot/src/master/resources/utilities/ich9deblob/src/gbe/gbe.c

tlaurion commented 4 years ago

So, to be able to generate gbe blobs (ich9gen wast obsoleted in favor of bincfg), one would need to adapt the x200 bincfg spec file to ICH6 series

@9elements @3mdeb anyone?

tlaurion commented 4 years ago

796 is fixed. So We have extracted and modified IFD in repo, GBE generated per bincfg, and ME neutered+deactivated. Now time to automated it #797 and this issue wil be resolved. Progress under #703

tlaurion commented 2 years ago

From https://github.com/osresearch/heads/issues/307#issuecomment-627629359

The MAC addresses seems to be in a fixed position at those hex offsets. My offsets match the ones you posted in #700 and they are also the same on my x220. I haven't tried modifying the addresses, I assumed there was a crc32 checksum or something that verified the mac's validity apart from the vendor prefix.

@Thrilleratplay BTW it seems there is no verification made on GBE checksums.

Dunno if you are going to be quicker then me, but it seems that if we find a quick way to extract GBE from flash, modify at offset MAC defined in /etc/config (or under board config at compilation) we could hack the MAC, and reinject it prior of flashing, we could have either user defined MAC and persistent randomized MAC in Heads from a new menu entry.

Thrilleratplay commented 2 years ago

@tlaurion You are saying that the checksum within the GBE blob is not checked? And it does not effect OS level drivers? Huh.

I want to create a python script that is more flexible than bincfg that allows a command line parameter or template to set the MAC. If a patch file is generated for the gbe-82579LM config the MAC could be set on compilation with correct checksum. Although, if the checksum is not utilized, a small C program probably could do a binary replacement of the MAC in HEADS as it already has Flashrom. However, I am not a C developer and cannot write it quick/efficient/safe.

tlaurion commented 2 years ago

@Thrilleratplay my idea was to bash script around busybox' hexedit from output flashrom -p --ifd -I gbe -r /tmp/GBE.ROM following this insight.

I tried to manually hexedit only de:ad:c0:ff:ee at both offsets, and then flash /tmp/GBE.ROM back

But then, bringing up Ethernet by loading e1000e results in: The NVRAM Checksum Is Not Valid.

I haven't checked further then this. But checksum is confirmed to necessary at least on x230 from that little test. Commented PR and crosslinked here.

Thrilleratplay commented 2 years ago

@tlaurion NVRAM Checksum Is Not Valid sounds familiar. I am trying to remember the errors I saw when testing/debugging the generated GBE blob. It is possible the checksum used to test that matched the original checksum. This is why I thought a small C program could do this and also calculate the checksum if needed.

tlaurion commented 2 years ago

@Thrilleratplay well i just modified de:ad:c0:ff:ee at both places with a valid one without changing the checksum here, so the error seems pretty valid to me.

Of course, if the whole region is computed in the checksum (on both regions which are exactly the same match the real checksum of what is expected, the error is legit here. I just had hopes that as reported in the PR referred above, it wasn't checked. But it clearly is, following reporte error.

I still think its possible to script something to extract the region, modify it and append checksum. Then duplicate as expected and reinject in GBE in backuo and flash back. But of course, a C program could do it as well.

Just thought a quick hack could be made and confirmed it can't as easily as expected. Checksum is needed.