Closed velaar closed 3 years ago
@velaar Yes. Seeing the same and it doesn't seem to be possible to circumvent atm. Its a result of the disabled checks which made the bios-patch possible in the first place.
Is it possible to sign the BIOS instead? I have not tried it but the original tutorial sign the BIOS instead of by pass the check bit. Also I am wondering if we can unlock CFG and re-flash back the original BIOS to keep the setting. Technically it should still remain the same value with BIOS update.
@buyddy Don't know really to what you are referring with "sign the bios instead", but from my understanding, its a checksum in the tpm which causes the problem. Don't know of any way to circumvent this (yet). What "original tutorial" are you referring?
You won't be able to reflash your unmodded bios via the external programer and keep your settings, as it overwrites the complete bios-chip (including the settings region). A bios-update on the other hand might work and is an interesting idea. But it would need to be flashed manual via the dos-utility (I think) as normally you can't reflash the same bios-version afaik.
Would love to hear results!
@velaar could you elaborate what you are describing as "ME password"? Don't know what that is/where it can be set and sounds interesting ;)
If you log into ME control panel (CTRL+ P) at BIOS boot time it forces you to set the password.
Applicable to vPro models only I think.
Sorry for short response. Will make some screenshots later today.
On Oct 29, 2020, at 9:15 AM, Benjamin Bender notifications@github.com wrote:
@velaar https://github.com/velaar could you elaborate what you are describing as "ME password"? Don't know what that is/where it can be set and sounds interesting ;)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tylernguyen/x1c6-hackintosh/issues/85#issuecomment-718744538, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA67YFSXFMSYDE5PNR4AAOTSNFTGPANCNFSM4S7TLRWQ.
@buyddy Don't know really to what you are referring with "sign the bios instead", but from my understanding, its a checksum in the tpm which causes the problem. Don't know of any way to circumvent this (yet). What "original tutorial" are you referring?
You won't be able to reflash your unmodded bios via the external programer and keep your settings, as it overwrites the complete bios-chip (including the settings region). A bios-update on the other hand might work and is an interesting idea. But it would need to be flashed manual via the dos-utility (I think) as normally you can't reflash the same bios-version afaik.
Would love to hear results!
"The modded BIOS does not need to be signed by thinkpad-eufi-sign. Just remember to replace 4C 4E 56 42 42 53 45 43 FB with 4C 4E 56 42 42 53 45 43 FF on the patched BIOS."
I was talking about Thinkpad-UEFI-SIGN. I think we bypass the check instead. But original tutorials online signs the mod BIOS. My experience with my old Y50-70 is that the bios settings won't be killed by bios update (dvmt pre-allocated memory size changed to 128M from 64M and BIOS update keeps it). My guess is that we could possibly edit the advanced menu and then flash back to the stock BIOS and keep the CFG Lock setting. Voltage and power limit can be done in user space with Voltageshift so the only thing that is actually useful is CFG Lock. So probably that would be the best way of handing TPM.
I think you can downgrade bios (tried that) and upgrade again. So you can just use Lenovo bios update tool to do it in windows. Quite painless.
For T460 and newer thinkpad that hex replacement is not recommended anymore. Check out thinkpad-firmware-patches README, were it uses fix_vendor_hashes script instead.
For T460 and newer thinkpad that hex replacement is not recommended anymore. Check out thinkpad-firmware-patches README, were it uses fix_vendor_hashes script instead.
seems that @benbender already tried that script and it will cause a reboot loop. Saw his issue over that site.
@buyddy you're correct. I would wait till @benbender 's answer on that issue, since it is still open.
seems that @benbender already tried that script and it will cause a reboot loop. Saw his issue over that site.
I believe this would be the result of using the older thinkpad-uefi-sign script that is for older machines, it is tested to work on xx20, xx30, and socketed xx40(and W541). Didn't notice the issue opened on uefiplayground :P
fix_vendor_hashes is for skylake generations, although i haven't seen any tests on the xx60 models, we have tested it on xx70, xx80, and xx95. X1C6 which this is related to falls under xx80.
MFG mode of the TPM is expected behavior
Lenovo's Phoenix UEFI implementation keeps even hidden settings that are in the advanced menus the way you left them after an update. Ones that are non-volatile like memory speed control also remain as far as i am aware.
Hey @digmorepaka, thanks for your insights!
Now I'm curious: So you had success with a xx80 Thinkpad, applying the paranoidbashthot-patches + fix_vendor_hashes.py
instead of the bin-replace? Whats the difference to using the bin-replace if the TPM isn't working either way?
@benbender something I've been thinking about recently is UEFI debugging. I think that with [test] firmware we should have access to low-level EFI debug. (Can really help us to fix some of the delays).
I wonder if we have an RS232, JTAG or USB debugging somewhere on X1C6. Didn't investigate much yet.
A rough example of what I'm talking about here
@velaar didn't looked into it either but would also be interested. The opencore-part is described by @khronokernel here: https://github.com/dortania/OpenCore-Install-Guide/blob/807e86082fedf290a383f7391d0ce49631a630de/troubleshooting/kernel-debugging.md (unmerged yet)
Now I'm curious: So you had success with a xx80 Thinkpad, applying the paranoidbashthot-patches + fix_vendor_hashes.py instead of the bin-replace? Whats the difference to using the bin-replace if the TPM isn't working either way?
Based on the initial report(T480 A285 X395/T495s) when the fix_vendor_hashes script was released and a few others it should have no issue. Currently I'm waiting for a response from a few people that i remember testing it to see if there were any additional steps required. I don't have a compatible machine on hand to test myself.
On top of that charlyo and the person who wrote the script started investigating missing KeyManifest with T470 on the discord channel where the collection of patches was developed.
From what I understand replacing FF FB disables Phoenix BIOSGUARD that protects ranges which aren't protected by Intel's bootguard, the script fixes the expected hashes so that it passes the check and lets the TPM operate.
I wonder if we have an RS232, JTAG or USB debugging somewhere on X1C6. Didn't investigate much yet.
Pch jtag is available on J8, not sure if you can enable it with JTAG ME images.
UART of the PCH is either terminated NC on the BGA ball or goes to the EC.
Doubt any of these are of use here but might aswel put it out:
EC jtag goes to the keyboard LEDs. To get EC UART you can set U234 pin 8 to high and get it through the audio jack.
@digmorepaka My issue seems to be confirmed for (at least) the T480 and the X1C6 (See https://github.com/sibradzic/UEFI-playground/issues/1#issuecomment-719706687). If you have any more infos about additional steps to make it work, I'm happy to test them!
Besides I'm having a look into JTAG possibilities and at first glance it seems that Intel DCI via USB would be the way to go (See f.e. https://casualhacking.io/blog/2019/6/2/debug-uefi-code-by-single-stepping-your-coffee-lake-s-hardware-cpu). Am I overlooking something why that shouldn't be possible on a Thinkpad?
(Edit: Source for a DCI cable - https://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html)
Thanks a lot for those infos. Very appreciated!
Am I overlooking something why that shouldn't be possible on a Thinkpad?
I don't see why it shouldn't be possible, all the ports on machines in question are directly connected to the Intel SOC. I was originally also trying to see if there were any EHCi debugging ports labelled in the schematic but i guess DCI has replaced it entirely.
DCI Secrets presentation states that they checked the T460s to be compatible, overall mainboard architecture per say hasn't really changed much from that model(arguably even earlier ones with new features like TB popping up from time to time). Definitely worth a try in my opinion.
Some updates on this:
MFG seems to be actually "manufacturing mode" and the way we got around bootguard
It seems to be possible to do some editing on the stockbios in NVRAM via ru.efi - but it has to be redone if the bios is resetted. Should help with CFG Lock & DVMT though...
The BIOS-patches we are using are screwing something up, I noticed in the meantime that UEFIPatch is already unhappy while applying them. Unclear to me if its possible to do the patches without the errors:
bb@bbs-MacBook-Pro t480-biosmod % ./UEFIPatch ./t480-original-bios-v1.34-resetted.rom ./xx70_xx80_patches_v6.txt -o ./t480-patched-bios-v1.34-adv-menu.rom
parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50
parseBios: one of volumes inside overlaps the end of data
parseFile: non-empty pad-file contents will be destroyed after volume modifications
patch: replaced 16 bytes at offset 3B60h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA
patch: replaced 16 bytes at offset 118D0h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA
Image patched
I'll try to do some further testing with BIOS 1.5 when Big Sur is out later this week
Some updates on this:
- MFG seems to be actually "manufacturing mode" and the way we got around bootguard
- It seems to be possible to do some editing on the stockbios in NVRAM via ru.efi - but it has to be redone if the bios is resetted. Should help with CFG Lock & DVMT though...
- The BIOS-patches we are using are screwing something up, I noticed in the meantime that UEFIPatch is already unhappy while applying them. Unclear to me if its possible to do the patches without the errors:
bb@bbs-MacBook-Pro t480-biosmod % ./UEFIPatch ./t480-original-bios-v1.34-resetted.rom ./xx70_xx80_patches_v6.txt -o ./t480-patched-bios-v1.34-adv-menu.rom parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50 parseBios: one of volumes inside overlaps the end of data parseFile: non-empty pad-file contents will be destroyed after volume modifications patch: replaced 16 bytes at offset 3B60h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA patch: replaced 16 bytes at offset 118D0h 04320B483CC2E14ABB16A73FADDA475F -> 778B1D826D24964E8E103467D56AB1BA Image patched
- I'll try to do some further testing with BIOS 1.5 when Big Sur is out later this week
I have tried RU before buying the device to flash the bios. The cfg lock bit on stock bios cannot be written into. (Some other places I can write).
I believe there is a way to set some parameter from OS. I had a very weird situation that I used -150 on the gpu voltage once in BIOS setting. Somehow this becomes the default everytime I reset my NVRM. Not sure how this happened though.
Can confirm: doesn't seem to be possible to write CFG Lock
or DVMT Pre-Allocated
via ru.efi
on the latest X1C6-Bios (1.5).
Did another flashing-session:
4C 4E 56 42 42 53 45 43 FB
is the only thing needed to force the TPM into MFG Mode
(aka manufactor mode)MFG Mode
will make the machine stop booting as Boot Guard
kicks in.Conclusion for now:
MFG Mode
is to be expected, no known workaround atmnon violatible
(NV). That's the reason why neither ru.efi nor grub are able to write those.PS: ~opened a bug at the UEFITool-Repo to notify them and clearify if those errors a problem on their end: https://github.com/LongSoft/UEFITool/issues/227#issue-746499159~ - Closed it as it is a known (non-)issue. See https://github.com/LongSoft/UEFITool/issues/172.
I have decided to revise the documentation for the patches collection repo thanks to this thread, I would highly appreciate if you guys could report what other machines you have tested to correct any inconsistencies with reality so it is easier for all of us! :D
https://github.com/digmorepaka/thinkpad-firmware-patches#compatibility-wip
Did another flashing-session:
- Bios 1.5 on the X1C6 works exactly as 1.48/1.49
- Binpatching
4C 4E 56 42 42 53 45 43 FB
is the only thing needed to force the TPM intoMFG Mode
(aka manufactor mode)- Any patch without forcing the TPM into
MFG Mode
will make the machine stop booting asBoot Guard
kicks in.- The errors using UEFIPatch mentioned above are happening with any patch. Seems to be rooted in UEFIPatch or the bios itself. It doesn't seem to be a problem with one of the patches.
Conclusion for now:
- It doesn't seem possible to patch the bios without loosing normal operation of the TPM as it is required to disable boot guard to apply the patches
- Therefor
MFG Mode
is to be expected, no known workaround atm- With working TPM any modification of the bios-settings (we need at least CFG Lock, DVMT) is forbidden as those vars are flagged as
non violatible
(NV). That's the reason why neither ru.efi nor grub are able to write those.- I think what we have now is the best we can get (for now at least)
PS: ~opened a bug at the UEFITool-Repo to notify them and clearify if those errors a problem on their end: LongSoft/UEFITool#227 (comment)~ - Closed it as it is a known (non-)issue. See LongSoft/UEFITool#172.
Have you tried to change cfg lock and DVMT size in mod 1.49 and then update to the stock 1.50 using the Lenovo tool? Curious if that will keep those values unchanged.
Can not set a TPM pass or reset the TPM from MFG mode after BIOS reflash. Also can't set ME password. I wonder if this community faces similar issues.
I recognize it is not directly related to the repo itself nor it is an issue.