Whitelist

[edmalho]

Can this project be expanded to whitelist cards, or even unlock overclock? I can provide the changes needed on the FL1 file.

[hamishcoleman]

That sounds useful! It's flexible enough that we could probably add that in, yes.

Nothing in the current build touches the FL1 files, so I think it would end up being a second build output.

Do you have a sample set of FL1 changes? I could look and see if anything suggests itself

[m-kozlowski]

As much as I would like you guys to succeed, I'm rather sceptical. I have no experience with unlocking overclocking, but i did remove whitelist from my t430 and t430s and there are few things that in my opinion make automation of this task non-trivial.

The point is to modify few JMPs from single bios module. Simple hex find&replace won't work here, as instruction opcodes differ between the bios versions. But even considering that we could sort this out with some heuristics, resulting module must be repacked back into some propertiary bios format. I don't know any details on this, as i've used this windows tool that did the job for me. I don't know if there are any linux equivalents. You can read more about the procedure here

Another problem is that series xx30 and up "introduced new Intel security features that make it impossible to flash the [unsigned] BIOS using software". So users will end up with FL1 file that fails flashing.

[hamishcoleman]

The bios update FL1 file is in a UEFI capsule format, the difficulty in patching it is usually because it needs to be signed (which can be side-stepped if you use a hardware programmer - that is what a lot of people seem to suggest). So at least, there is some hope of automating it - just the signing that is difficult.

If there is a process for creating valid patches, then the repo could just store a different patch for each BIOS version - the moving instructions and limits on find&replace all apply to the EC firmware too, and just keeping a patch set for each version has worked there. Event if we cannot create signed updates, it might be useful to provide a resource for people to create binaries to use with a hardware programmer.

Thanks for the links - I'll have a look at them when I next get a chance.

[edmalho]

The UEFIPatch can already change the bios. The thing is UEFIPatch it's a generic tool to change a bit for Hackintosh Power management. I didn't get into the code to understand how it does it, but since the EC is already "unlocked" maybe it isn't so far fetch to try change the bios. I found a russian blog with some modifications explained https://habrahabr.ru/post/211879/ This one https://habrahabr.ru/post/182676/ explain how to get the full unencrypted bios without a programmer. The procedure now is like this: -Read the chip. -Use the UEFITool to extrat the body of the sections we want to modify -Patch the bodies. -Replace the bodies with the patched ones in the UEFITools -And write the moded dump to the chip. UEFITools simply compress the sections and checksum everything. Neat'n easy!

[hamishcoleman]

Unfortunately, the BIOS and the EC use completely different "locking" systems. So our success with the EC does not help with modding the BIOS - and I am fairly sure that there is some signature that needs to be correctly added to the BIOS to allow it to be uploaded without an external programmer.

Also problematic is that the UEFITool is a GUI interface that is not automatable.

However, if you had patches that apply to the UEFI sections, there might be a way to add and automate some or all of this.

[rad4day]

The only way to really mod the bios on some of the Thinkpads seems to be actually disassembling the Notebook and hooking the chip up to an external flasher. (Which in some cases isn't really possible without a hot air station and desoldering the chip). Which is quite a shame.

[hamishcoleman]

@rad4day you are right - but we could still start collecting repository of known patches to help with building a new flash image once you have downloaded (and backed up) your current image.

[edmalho]

well i have a w530 and on the schematics i found a solder pad (CN100) on the motherboard with spi and jtag connections. There is no necessity to fully disassembly the laptop anymore, now we only need to remove the palmrest to solder cables and leave them hidden bellow the keyboard. It is possible that other laptops with "hidden" bios chips have this kind of shortcuts. Do you want me to create a list of laptops with easier places to connect a programmer? it is possible to remove the bios write protection, so even we don't find the signature key now we only need to use a programmer one time:

BIOS lock removal What : removal of protection from the firmware of modified UEFI images by the built-in programmer. Why : with a large number of experiments with UEFI get every time the programmer quickly gets bored, and firmware is faster (using QuadSPI protocol instead of the usual SPI in the case of an external programmer). Where to search : in chipset drivers, most often in PchInitDxe (another version of the mod is in BiosWriteProtect) Modification method : the modification version of PchInitDxe is fully described here in English, so I'll just give an idea. It is necessary to find the BIOS Lock Enable (BLE) bit entry in the BIOS_CNTL register of the chipset and prevent it. You can do this in several places, for example, here: 48 8B 4C 24 40 mov rcx, qword ptr [rsp + 40h]; Load the RCX address of the PchPlatformData structure 48 8B 41 50 mov rax, qword ptr [rcx + 50h]; And in RAX, the address of the child structure of LockdownConfig F6 00 10 test byte ptr [rax], 10h; Check if the fifth bit is set (BiosLock) 74 25 je 0000000180001452; If not installed, jump over the entire code below 8A 50 01 mov dl, byte ptr [rax + 1] B9 B2 00 00 00 mov ecx, 0B2h; E8 A2 5A 00 00 call 0000000180006EDC 4C 8D 87 DC 00 00 00 lea r8, [rdi + 000000DCh]; In RDI, the base address of the LPC chipsets is the base address, and 0xDC is the BIOS_CNTL 33 C9 xor ecx, ecx 4C 8B CD mov r9, rbp 33 D2 xor edx, edx 4C 89 44 24 20 mov qword ptr [rsp + 20h], r8 E8 AA 76 00 00 call 0000000180008AFC; Install the lock You can change JE to JMP, but sometimes, instead of a short jump, you get a long one that has to calculate the offset in addition, so it's better to change the test to any command that sets the ZF flag, for example to xor rax, rax (48 31 C0), and the possible size difference correct commands by adding NOPs. If you did not find the desired code in PchInitDxe, you can change the BiosWriteProtect driver so that you can bypass the registration of the SMI handler located in it, which sets the BLE bit when trying to reset it, and then it is enough to reset this bit to unlock the firmware. I have worked perfectly the above method, so I have not tried this option yet, and therefore I will not describe it in detail.

[edmalho]

https://drive.google.com/drive/folders/1C-60q2ndgsqU4J1NZqyiwrCvRM4vNDKL?usp=sharing

[edmalho]

some intel me info: www . mediafire . com/?iwscmnadf5icnxq

[edmalho]

Ok it's possible to show the hidden advance tab without rewriting the bios, but its necessary write access to nvram(it's unlock on thinkpads?): https://github.com/bobafetthotmail/insydeH20-advanced-settings-tools

[edmalho]

this is the patch file(UEFIPatch) to implement the wifi whitlist, advance tab, cpu multiplier and hackintosh power. patches.txt

[edmalho]

This one change the Date Tab with the Advance Tab

SystemFormBrowserCoreDxe | W530

32442D09-1D11-4E27-8AAB-90FE6ACB0489 10 P:04320b483cc2e14abb16a73fadda475f:778b1d826d24964e8e103467d56ab1ba

[edmalho]

ok for cpu multiplier management: F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:30488b4338f6000874080fba6c243014:30488b4338f60008eb080fba6c243014

[edmalho]

Hackintosh Power management: F7731B4C-58A2-4DF4-8980-5645D39ECE58 10 P:44243080fb0175080fbae80f89442430:44243080fb01eb080fbae80f89442430

[edmalho]

the only thing i don't know is how to kill the write protection

[patrickhgb]

@edmalho do you mean write protection = secure flash?

Secure flash can only be defeated by hardwarely flashing your modified bios.

[edmalho]

if you first hardware flash a modded bios with the write protection bypassed the next flash will be allowed and subsequently until you flash a official one again.

[rad4day]

I can confirm this behaviour on the T430s.

[edmalho]

@rad4day do you have the bios with write protection disable? can you send me the dump?

[rad4day]

@edmalho well I replaced mine with coreboot. But I'm probably able to remove the write protection from the original image. I'll take a look at it in the next days

[rad4day]

@edmalho I finally looked over my files. It's pretty easy actually. You have to dump your bios and just use ifdtool to unlock it. The only change which occures on the binary is the following:

$ diff <(xxd T430s.rom) <(xxd T430s.rom.new)
7c7
< 00000060: 0000 0b0a 0000 0d0c 1801 0808 ffff ffff  ................
---
> 00000060: 0000 ffff 0000 ffff 1801 0808 ffff ffff  ................

As I don't want to post the images publicly (as I'm not sure on the license on those) It would be kind to let me know your Email ;)

[edmalho]

https://forum.ixbt.com/topic.cgi?id=17:53248-29 @tiahoj.tar.gz https://github.com/ValdikSS/thinkpad-shahash this one found a way to change the Lenovo public key with a personal one --ONLY FOR x220-- to create the keys run: openssl genrsa -3 -out my_key.pem 1024 openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der openssl rsa -pubin -inform der -in my_key_pub.der -text -noout and then copy (in hex) the modulos part output by lhe last command to a file called my_key_pub run ./gethashes.py --output recomputed_fw.FL1 modified_fw.FL1

[JCBuck]

@edmalho Is Lenovo's public key normally used to also verify official UEFI BIOS capsule updates that flash on restart?

If it is then it may be useful to be able to sign our own FL1 and use the official mechanism to update bios (after replacing with our own public key of course)

[edmalho]

@JCBuck, ValdikSS discover the way that TPM verifies the bios at startup. so if you mod a bios the TPM validation fails and at startup the laptop beeps in 2 blocks of 5. so if you need the TPM and don't want the annoyance, you have to change the signatures. i don't know what methods they use to verify updates but if it is something like the TPM it would be perfect. Simply change the public key on the firmware and and voyla security and convenience

[edmalho]

So the script don't work for me, the bios structure change... Since ValdikSS didn't explain it very well, i made this howto: with a hex editor open the bios file and search for TCPABIOS In TCPABIOS we find a list of sha1 hashs of every file inside the 1st(?) volume called EfiFirmwareFileSystemGuid(and with a GUID 7A9354D9-0468-444A-81CE-0BF617D890DF). In my case i have only one, FvMainCompact: after IBMSECUR the entries starts in hex like this: 00 FD 27 (20 Bytes hash) (16 bytes header), 01 FD 27 (20 Bytes hash) (16 bytes header), 03 FD 27 (20 Bytes hash) (16 bytes header)... and so on. the first byte increases by 1 for every hash/file FD identifies the type file? 27 identifies the start of the hash The header: the 1st 4 bytes is the offset of the file (the bytes order is inverted) after that is the size of the file, 6 bytes (also inverted) them comes 03 00 00 00 00 00 (I didn't found what this is...) The list terminates with 00 00 27 and 36 bytes of 00's After all the mods, correct the hashs, sizes and offsets of the files that were changed sha1sum file.efi.ffs Copy the TCPABIOS block(with all the hashs and continuos 00's) to the file mod_TCPABIOS Calculate mod_TCPABIOS hash: sha1sum mod_TCPABIOS Copy the hash to the file mod_TCPABIOS_hash, like this: Run: openssl genrsa -3 -out my_key.pem 1024 openssl rsautl -inkey my_key.pem -sign -in mod_TCPABIOS_hash -raw > mod_signature Replace the lenovo signature with the custom mod_signature(located between FF FF 83 and TCPACPUH) openssl rsa -in my_key.pem -outform der -pubout -out my_key_pub.der openssl rsa -pubin -inform der -in my_key_pub.der -text -noout Search FF 12 04 replace the lenovo modulus with the custom. (modulus starts with 00)

[edmalho]

i'm trying to find the verification part of the firmware update. what and how it does it, really. I'm posting the flash updater to any interested to help Section_PE32_image_C8AB0F4E_26FE_40F1_9579_EA8D30D503A4_SystemFlashUpdateDriverDxe.efi_body.efi.tar.gz

[pgera]

This thread (https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-W520-BIOS-1-42-whitelist-removal-8BUJ21UC) has quite a bit of information on the various patches. @edmalho already mentioned a few of these. From the remaining ones, these seem to be of interest:

• BIOS lock removal (EFI IFR too can be modified to get same result)

• Disable SMI Lock and BIOS Lock (CodeRush AMI Bios Developer)

• Unlock Firmware Regions (CodeRush Unlock Descriptor, ME, Bios)

Note, all of these still require a hardware programmer, but I think once you flash a modified version, future updates shouldn't require a hardware programmer. It should also be possible to switch back and forth from coreboot and patched BIOS without hardware programmer ? @edmalho, are you able to test these and incorporate them in your patch list ?

[rad4day]

@pgera It should also be possible to switch back and forth from coreboot and patched BIOS without hardware programmer ?

It is. As coreboot doesn't set the lock bits for the bios chip regions. You can use flashrom with the "internal" programmer to just overwrite your bios chip while using the laptop. After flashing the original bios, the lock bits will be set again. (unless you modify the image to not be locked)

[pgera]

@rad4day , based on your earlier post that mentions the change from 0b0a to ffff, that seems like the method to unlock protected regions including ME. That is also mentioned in the thread. The other patch in that thread mentions this: "After both modifications BIOSWE=1 and SMM_BWP=0 in BIOS_CNTL register, that allows flashrom to work normally." So, I think both these patches would be needed in the OEM bios if you want to unlock the SPI chip entirely, including the protected regions. This should allow flashing coreboot and me_cleaner with the internal programmer.

As for flashing without SPI programmer, there were some SMM vulns which were patched sometime in 2016. If your BIOS version is older than that, it SHOULD be possible to set the bios control bits. In fact, even with the latest OEM bios, chipsec reports the boot scripts for s3 resume to be unprotected. I tried some of examples in chipsec's tools.uefi.s3script_modify. They don't seem to work, but perhaps someone who knows more can make it work.

[JCBuck]

@pgera I can confirm the SMM vulnerability method works with a bios version of 2.62 or older on W530 (3/31/2015) where there is a random lenovo DXE or PEI module that could be exploited for SMM privilege escalation. I've been meaning to do a write up for many months but in essence it's modifying the S3 resume boot script to disable BIOSWE, and SMM_BWP like you said, but also nullifying the protected region registers for the SPI Flash. I've gotten this to work on a T530 and W530 and could flash a modified bios using the intel fptw64 utility. I believe it's possible to downgrade the efi bios to this version to use the exploit.

I can't remember exactly, but I believe this does not allow flashing over ME regions or ethernet rom? region as those permissions are flashed directly onto the SPI chip itself. So this is another line of defense even after configuring the chipset to allow flashing to the SPI chip and most likely a hardware programmer is necessary to flash over ME.

[pgera]

@JCBuck Lenovo has bios rollback protections. If you are running anything moderately new, you can't go back to the version before the SMM patch. However, it would still be interesting to see your writeup. The s3 boot script still shows up as unprotected in chipsec, so there may be something interesting to look for.

The other thing worth patching is the SMM handler code that checks for Lenovo's public key. Even if you flash with an SPI programmer, you don't want to leave BIOSWE and SMM_BWP disabled as that's a security issue. Yet, you want to retain the ability to flash internally in the future. So you need some way to patch the handler to check your public key instead.

[JCBuck]

Yeah, I agree with the security implications and was investigating the idea of somehow signing your own bios and putting in your own key.

I think there was bios roll back protections but i want to say i definitely was on a much later bios and somehow was able to downgrade to this version. It may have been a bios setting or it may have been messing with winflash switches that just let it happen. I used similar switches to flash the EC region for the keyboard keymap mod, and just used appropriate switches to target the bios with .fl1 i think it was.

On Wed, Aug 29, 2018, 5:43 AM pgera notifications@github.com wrote:

@JCBuck https://github.com/JCBuck Lenovo has bios rollback protections. If you are running anything moderately new, you can't go back to the version before the SMM patch. However, it would still be interesting to see your writeup. The s3 boot script still shows up as unprotected in chipsec, so there may be something interesting to look for.

The other thing worth patching is the SMM handler code that checks for Lenovo's public key. Even if you flash with an SPI programmer, you don't want to leave BIOSWE and SMM_BWP disabled as that's a security issue. Yet, you want to retain the ability to flash internally in the future. So you need some way to patch the handler to check your public key instead.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hamishcoleman/thinkpad-ec/issues/70#issuecomment-416938606, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGna1sQ4doZzOAW60rEgUdS77KH5Tp4ks5uVoxkgaJpZM4SssSR .

[pgera]

Interesting. I found this: https://www.bios-mods.com/forum/Thread-Lenovo-Rollback which mentions winflash. So you may be right. The rollback protection may be entirely client side in lenovo's utility. I don't have an SPI programmer yet or backups of the chips. So I'm a bit reluctant to try too many things. If someone can confirm the rollback method, we should have a working solution with the SMM vuln.

Also, about ME regions and ethernet ROM, that needs the separate patch that changes from 0b0a to ffff in addition to the bios control bits. Did you have that in your modified version ? Ideally, it should unlock all regions.

Edit: Found this repo: https://github.com/Cr4sh/UEFI_boot_script_expl

[edmalho]

Hello everyone @pgera sorry i'm not interested in removing security locks.. uefitools has linux exec now!

[pgera]

@edmalho , I am not suggesting removing the locks for production. This is only for experimentation if you want to flash different things back and forth without hardware programmer. Without support for self-signing, it is impossible to update the BIOS with the internal programmer. Also, without self-signing, the locks seem quite moot if you could just do a downgrade attack.

[pgera]

Hi everyone. I managed to downgrade the bios, and run chipsec to enable bios_we. This was my command: sudo chipsec_main -m tools.uefi.s3script_modify -a add_op,pci_wr,0x1f00dc,0x9,1

[*] BC = 0x09 << BIOS Control (b:d.f 00:31.0 + 0xDC)
    [00] BIOSWE           = 1 << BIOS Write Enable 
    [01] BLE              = 0 << BIOS Lock Enable 
    [02] SRC              = 2 << SPI Read Configuration 
    [04] TSS              = 0 << Top Swap Status 
    [05] SMM_BWP          = 0 << SMM BIOS Write Protection 

I haven't unlocked the protected regions yet. Can I flash with flashrom internally now in a safe way ? Anyone with experience ?

[JCBuck]

The protected regions are required to be unlocked in order to flash it or else it will fail to flash.

On Sat, Sep 1, 2018 at 4:31 AM pgera notifications@github.com wrote:

Hi everyone. I managed to downgrade the bios, and run chipsec to enable bios_we. This was my command: sudo chipsec_main -m tools.uefi.s3script_modify -a add_op,pci_wr,0x1f00dc,0x9,1

[*] BC = 0x09 << BIOS Control (b:d.f 00:31.0 + 0xDC) [00] BIOSWE = 1 << BIOS Write Enable [01] BLE = 0 << BIOS Lock Enable [02] SRC = 2 << SPI Read Configuration [04] TSS = 0 << Top Swap Status [05] SMM_BWP = 0 << SMM BIOS Write Protection

I haven't unlocked the protected regions yet. Can I flash with flashrom internally now in a safe way ? Anyone with experience ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hamishcoleman/thinkpad-ec/issues/70#issuecomment-417842902, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGna14f4fxfCWW64u_ELmGROjwmys0Uks5uWkXygaJpZM4SssSR .

[pgera]

@JCBuck , yes just discovered that. Do you remember how you disabled the protected regions ?

[JCBuck]

Looks like chipsec makes it very easy to write to the s3 bootscript, which i did manually before, but basically need to write to 0 to the 5 pr registers which should be memory mapped. I don't remember their exact location though right now but these tools should say

On Sat, Sep 1, 2018, 4:40 AM pgera notifications@github.com wrote:

@JCBuck https://github.com/JCBuck , yes just discovered that. Do you remember how you disabled the protected regions ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hamishcoleman/thinkpad-ec/issues/70#issuecomment-417853648, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGna4X1JR3FdK3qMVsBi97L7r_U-kCsks5uWnIrgaJpZM4SssSR .

[rad4day]

@JCBuck Just remember that you have no way to recover if you flash a faulty bios image and then reboot. Depending on the device you may need to de-solder/replace the chip to reliably re-flash a working bios.

[pgera]

I was able to unlock the protected regions too. There is a separate flockdn register that needs to be reset early in the boot script. This was the command for that: sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6008,0x2 Once you do this, you can reset the protection registers from the OS. You don't need s3 boot scripts for that. I haven't tried flashing anything yet.

[JCBuck]

@rad4day Yeah, I do have hardware to manually flash need be.

@pgera yes that can work too, i think in my case i wasn't able to find an operation that was setting the flockdn register in the boot script, but I'd have to check again i may have just missed it since i too had to set the pr0-pr4 early in the script. On Sat, Sep 1, 2018, 9:15 AM pgera notifications@github.com wrote:

I was able to unlock the protected regions too. There is a separate flockdn register that needs to be reset early in the boot script. This was the command for that: sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6008,0x2 Once you do this, you can reset the protection registers from the OS. You don't need s3 boot scripts for that. I haven't tried flashing anything yet.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hamishcoleman/thinkpad-ec/issues/70#issuecomment-417869955, or mute the thread https://github.com/notifications/unsubscribe-auth/AFGna9lFOQ0jCDHXqi85ULKyHnoFKPn0ks5uWrKTgaJpZM4SssSR .

[pgera]

@JCBuck , how do you move to a later bios in this mechanism ? Once the registers are unlocked, you can flash the modified version of the same bios (or even a newer one?) with fptw64, but that is just the bios region. How do you get to a newer fd region ? When you update from the regular update utility, that updates the fd regions too, right ? Also, what is the difference between the fl1 and fl2 files. When I downgraded, I ran winflash64 with the fl1 file. When does the fl2 file come into play ?

Edit: So the flash descriptor region itself is probably not updated between even full bios updates, but I'm guessing that the ME region is. My current flashrom output is FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Management Engine region (0x00003000-0x004fffff) is locked. I'm guessing that the first one can be ignored, but we need to figure out how to get to the latest BIOS+ME with software only.

[JCBuck]

Right, I believe you cannot actually configure the FD since they're read from the SPI flash itself, which means I think you have to use a hardware programmer. There is another mechanism used for OEM manufacturers that if you short a specific pin on the southbridge? or SPI flash chip? it will unlock all of the FD for that boot.

FL2 is the EC firmware, FL1 is UEFI bios i believe with some header information iirc

[pgera]

So we cannot get to the latest patched bios using this method ? I get that unlocking the FD would need a programmer, but if you just want to apply the bios patches and leave the rest as is at the latest versions, is that doable ? The BIOS_CNTL can already be unlocked. If we patch flockdn in the bios too, would that allow us to use the vendor utilities to flash a patched FL1 file ? If that brings the rest of the stack up to the latest versions, that should be good enough

[JCBuck]

I'm not sure what you mean by latest versions, (of which?) what do you mean by vendor utilities? (lenovos' default winflash package?) Yes you can certainly patch latest bios versions from Lenovo to prevent them from toggling BIOS_CNTL and SMM_BWP, FLOCKDN etc

there's a separate EFI program that is used to flash a new bios in a capsule after a restart that is loaded by winflash and I believe it verifies if it has a valid signature

[pgera]

@JCBuck I don't know if the ME/GBE/FD regions are updated when you update the BIOS using the regular lenovo's winflash. Are those things a part of the FL1 file ? Essentially, we can only update the BIOS region using fptw/flashrom. When we do a rollback, is it also rolling back other regions ? The end goal is to have latest patched BIOS + latest ME/GBe/FD.

[JCBuck]

No, I don't believe lenovo update those regions with their bios updates. Generally ME/GBE don't get updated, and a separate tool from Intel is used for those. I think even then, they cannot be updated if the FD is configured to lock them down. I believe users who wanted to update those regions, for the purpose of say, getting a newer generation of Intel processors working on an older chipset or something, it needed to be hardware flashed from what I read.

some more info here: https://www.win-raid.com/t3553f39-Guide-Unlock-Intel-Flash-Descriptor-Read-Write-Access-Permissions-for-SPI-Servicing.html edit: it seems depending on the OEM/ODM it is possible (E3 E4 E5 E6)

[pgera]

Ok. In that case, I believe this method is good enough for updating or rolling back the BIOS region, and patching it as desired. For those who want to use the chipsec method, here's the summary of all the commands:

# Tested on W530 with BIOS g5uj21us. 
# You can rollback to older BIOS with winflash64.exe /sd /file <path_to_.fl_file> after disabling rollback protection in the bios settings

# BIOS_CNTL
sudo chipsec_main -m tools.uefi.s3script_modify -a add_op,pci_wr,0x1f00dc,0x9,1

# FLOCKDN
sudo chipsec_main -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xFED1F804,0x6008,0x2

# S3 suspend after this. Can be done with systemctl suspend

# After resume:
sudo chipsec_util mmio write SPIBAR 0x74 0x4 0xAAF0800
sudo chipsec_util mmio write SPIBAR 0x78 0x4 0xADE0AD0
sudo chipsec_util mmio write SPIBAR 0x7C 0x4 0xB100B10
sudo chipsec_util mmio write SPIBAR 0x80 0x4 0xBFF0B40

# Test with this:
sudo chipsec_main -m common.bios_wp
# Expected output:
[x][ =======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x09 << BIOS Control (b:d.f 00:31.0 + 0xDC)
    [00] BIOSWE           = 1 << BIOS Write Enable 
    [01] BLE              = 0 << BIOS Lock Enable 
    [02] SRC              = 2 << SPI Read Configuration 
    [04] TSS              = 0 << Top Swap Status 
    [05] SMM_BWP          = 0 << SMM BIOS Write Protection 
[-] BIOS region write protection is disabled!

[*] BIOS Region: Base = 0x00500000, Limit = 0x00BFFFFF
SPI Protected Ranges
------------------------------------------------------------
PRx (offset) | Value    | Base     | Limit    | WP? | RP?
------------------------------------------------------------
PR0 (74)     | 0AAF0800 | 00800000 | 00AAF000 | 0   | 0 
PR1 (78)     | 0ADE0AD0 | 00AD0000 | 00ADE000 | 0   | 0 
PR2 (7C)     | 0B100B10 | 00B10000 | 00B10000 | 0   | 0 
PR3 (80)     | 0BFF0B40 | 00B40000 | 00BFF000 | 0   | 0 
PR4 (84)     | 00000000 | 00000000 | 00000000 | 0   | 0 

[!] None of the SPI protected ranges write-protect BIOS region

I'll wait for a programmer before more experiments. I think most of the problems are solved in principle. The main thing left is self-signing.