After a tiny bit of reverse engineering: Yes, the structure of the EFI updater is as I expected.
It boots the shell and if not aborted will execute the startup.nsh script, that will simply execute “fwupdate.efi --allupdate”
you can hit escape and operate everything from the shell manually
fwupdate.efi calls itself “framework_tool: Swiss army knife for Framework laptops”
it can read versions, read charging state (in detail, it distinguishes charger, connected, battery state and battery charging) check header information of capsule files.
retimer updates in EFI installer are valid capsules, the main firmware is not
fwupdate.efi seems to execute the framework-firmware-update\res\firmware.nsh script with arguments like “[path_to_firmware folder] pd flash-left” which will actually call the other efi executables that do the actual updates, like H2OFFT.efi, CyPDADLt1.efi. There seem to be no obvious references to the ME update in there
FWUpdLcl.efi is the official Intel ME Updater. It executes, it reports the same program version as the Windows variant that is used as part of the Windows update process. It can read the current ME firmware version, the version of the ME update and seems completely capable of running the update. It just looks like it is never called by the fwupdate.efi that manages all of it. But executing it manually on the shell would work.
By the features fwupdate.efi has, it looks like it is intended to read all current versions and critical settings to determine what needs to be updated, in what order etc. And it only has a placeholder to determine the current ME firmware version. And so it does nothing with that.
But when you consider that the Windows updater simply executes unconditionally FWUpdLcl.exe with “-allowsv”, which forces an update of the ME firmware every time the installer is launched, even if the firmware is already the same, it is not like the Windows installer does a whole lot of sanity checks before it simply hands over to Intel’s updater to apply the update. If the other Retimer and BIOS updates where to fail or not complete after the ME update, the versions would be desynchronized with the officially released Windows updater.
An actual, technical explanation of why the EFI installer cannot just launch the ME updater in the same way would be nice, to understand what about that is actually holding Framework up for over half a year, when it is not the case, that you just did not have the time to look at it at all.
Also adds to the list of things that you need to explain: how did you manage to ever publish that updater if you find that is a critical problem. Clearly you packaged the ME updater and firmware in it with some kind of plan. And why would you not tell beta testers that already have used the EFI Updater before it was depublished that their update is incomplete or how it can be completed. If unmatched ME and BIOS versions were a problem, you’d need to tell people that they are in a unsupported state and how to recover. Even if you’d have to recommend the Windows installer for that, as you are already doing.
Note: I have not actually executed any updates with the pulled EFI updater, only confirmed that it can access and for example dump the current ME firmware. And if fwupdate.efi would internally construct the path to FWUpdLcl.efi from single characters, instead of hardcoding the full path as for all the other binaries and executables, I would have missed that.
But I’d consider @pixelforest post as confirmation, that the ME Updater is actually never called, even though it looks to be just a single commandline to by executed on the EFI shell to fix that.
I’d be curious if any of the customers that have used the EFI updater as it was originally intended actually has the new ME firmware on their Framework or if it actually stayed the same.
Using the EFI updater, aborting startup.nsh (you could also edit the “–allupdate” argument out of it to defuse it from auto-executing actual changes to firmware).
Once on the shell, executing “framework-firmware-update\firmware\FWUpdLcl.efi -fwver” will read out the currently installed ME version. This is an alternative to ways to get that version from within Linux or from the BIOS itself. I am not recommending people to actually use that to update ME, before Framework confirms anything or you want to risk your device. I am just trying to understand where Framework stands and what they plan and need to do, if they are not able to simply tell us after making many posts about wanting to improve communication.
And I am also trying to fact-check the non-technical and vague things they claim.
The main page they mention Intel CSME 16.0.15.1810v3.1
while under “enhancements” they mention: “Update Intel CSME firmware to 16.1.30.2269v4_A0_Corporate”
I just checked in my bios, (ive ran the EFI update, like you concluded, Intel ME dint get updated)
Im on Intel ME 16.0.15.1810 / CORPORATE
InsydeH20 Bios is HFW30.03.08
(I rechecked the video I took of the update process, no mention of intel ME engine ever checked or updated)
Thank you for the answer. After using the Windows updater / manually installing the different firmwares from Windows, BIOS shows “16.1.30.2269 / Corporate”.
ME-Updater from EFI Shell or Windows would show:
The last command is the actual command to run the update. And it aborts on my device because that is the version that is already on it and I did not want to risk actually forcing it to run just yet.
Edit:
So without an actual answer and explanation from Framework, from this I conclude that
Note: We have removed the EFI update for now until we improve the stability of this update method based on user feedback below.
is a lie or at least obfuscation. And the actual & more important reason they do not want to admit to, is that they produced a half-baked updater or simply failed to communicate the instructions to run all of the update internally. Or the update process would actually brick the device. In which case I find it suboptimal to ever publish it anywhere and leave the EFI installer still hosted and not warn of it.
And since it looks to be the official updater from Intel, any problems with using it would most likely be a platform problem. I.e. a fault already in the BIOS that confuses the updater or makes it incompatible with what Intel defines as correct behavior.
Edit2: the backup dump the ME updater can create is identical to the one the officially released updater for Windows makes. If the updater does not fail somehow due to a privilege problem (i.e. the ME firmware is not writeable / modifiable for some reason. Would fail before it has a chance to make changes to the system), I find it hard to believe that it would brick. But the clear risk remains.
Edit3: confirmed it runs perfectly. Past users have already found that manual ME update and successfully ran it. New installer release uses the same exact updater with same arguments.
you command seemed to indeed run fine. and confirmed the installed ME version.
So it seems EFI can update all, but they disabled the CSME portion (for some reason), Im not sure why Id like to update the ME section tho. would this be the cause of some PCI stuff not working like when “they” disabled ME on other older platforms? Feedback from FW would be nice. (I prever a secure main Firmware and skip all this stuff and just get Coreboot… I dont mind a weird not fancy gui to do stuff) offtopic.
That backup, binwalk is not seeing much. compressed?
ME is deeply involved in Intel’s stuff. It may do certain system management actions. It provides a lot of functionality, like the firmware TPM (that FW does not use as far as I see), DRM support for Windows. ARC GPUs are updated through it.
It is probably involved in managing standby modes on some level.
It has been encrypted forever, because it is part of the chain of trust for Intel. ME can undermine every piece of security the processor or OS otherwise try to provide. And ME has functionality like remote management and code execution (like AMT with running and orchestrating virtual machines running in the background scanning for problems, attaching virtual CD drives to remote install an OS or do maintenance or decouple an infected system from the corporate network).
So most of the reasons I have seen for ME updates is fixing security issues in there (I believe it is internally based on some embedded Linux. At least it was in the past. Just with vast access to the system. Also the reason why people want to disable it. It is propriatary code that cannot be audited). But because the BIOS needs to interact with it during bring-up they typically want a specific BIOS version paired with a specific ME version to exclude any compatibility issues with untested combinations. I have no idea how often ME updates might introduce breaking changes in its API, so that running unsupported combinations of ME and BIOS could cause instability as ME does not behave how BIOS expects. The people building their own EFI installers for 11th gen have explicitly not been doing the ME update (lack of updater, they are reusing an older EFI installer without the ME updater). And I have seen no reports of sth. that I would suspect to be caused by non-matched ME versions. But the possibility cannot be excluded.
And Intel Bootguard sadly (no idea if this emediatly influencing ME) but thats turned on on these machines. This might be the very last Intel/AMD I buy. Alott we dont know for sure with current gen Intel ME, previous ones where indeed definitly alott involved or could potentially have. Disabling it (as much possible) while maintaining normal operations would be preferred.
I have not looked deeply into it. But as I understand Bootguard is just Intel’s marketing name for authorized boot and their root of trust.
A manufacturer fuses their signing / encryption keys in there. The processor will only boot code signed to match. So you theoretically cannot undermine security of SecureBoot / BIOS etc. by flashing a different BIOS that skips security.
As long as you do not find exploits in the BIOS itself.
Basically Intel’s version of a locked Android bootloader. Only that the bootloader we are talking about is part of the platform. And the manufacturers BIOS is loaded by it. You want that unless you are a developer of BIOS or want to self-sign everything.
AMD will have an equivalent for the exact same reasons.
Edit:
But yeah, that kind of thing will prevent you from maintaining yourself everything it “authorizes” / authenticates as a result. But not having anything means anybody with access to the platform could place a BIOS level rootkit into your platform that you won’t be able to see. And they would not even need to rely on any exploit.
Edit2: without sth. like it, there’d be almost no reason to fix BIOS security issues like LogoFail, because it’d be harder to exploit them than just updating the firmware directly.
Update: I finally manged to update.
I realized I could uninstall the update which cleared the error in the device manager so rerunning the msi did restart the upgrade process.
I still only saw one progress bar through the whole thing but it was way longer than the other attempts. Maybe some things did upgrade before so maybe that’s why and why some USB ports were being weird.
I guess the update silently fails if you don’t have the laptop plugged in to power which I don’t think is specified anywhere. Or maybe I was just very unlucky on my first attempt.
And it looks like the USB ports that were acting weird are now working properly again.
Ow, thats some detail I dont see mentioned in the first post indeed:
Ensure your Framework Laptop is plugged into power and has at least 20% battery and we also recommending unplugging any external devices (eGPU, hubs, etc.).
Indeed it was clearly written on the dedicated page, I really did missed it then oops.
Anyway I eventually found out in the end but it was complicated to know that this really was the issue.
And the fact that maybe some things were updating fine without power where the main firmware was not might be a bit concerning.
I tried installing the new 3.08b bios update from a windows 11 install on an external usb-c connected ssd. It did not work. It would show the progress bar and reboot over and over and I eventually had to force it to quit. It did not update anything. I’ll wait for the UEFI update to be officially released by Framework.
As the windows updater is now released: is there a simple way to boot into a usb stick and make the update for Linux users ?
I am thinking thigs like MS DOS like copycats we had in the old days for updates…
When the beta was released, some people forced the ME update via the shell (including me ). My framework has not had any issues since and I did not need to install Windows. So I am not sure why they are so hesitant on the EFI installer.
That said, you probably shouldn’t do that and wait for a fix from their side. Such operations can probably brick your laptop.
If you mean booting into Windows from a USB stick then yes, you could boot into a Windows-to-Go installation. To create such an installer though you would need access to a Windows PC in the first place and then use the Rufus tool and create a USB drive there using a downloaded ISO image. I don’t know if there are any incompatibilities with this approach though.
I’ve used these instructions by @leorize to update my BIOS, including CSME to the beta version using the EFI method and it’s been running great for months now.
Support doesn’t seem to recommend it so I won’t either, but it does seem viable and overall the update process isn’t as precarious as it might seem
That would be one of those communication problems. Because publicly, they never spoke on it. They never mentioned the ME-updater’s existence.
And since I tried to find out how the ME-updater would be called (and could not find anything obvious), it seems more likely, that they had internal miscommunication.
Someone designed the EFI updater for people to manually run the ME updater from the shell. But they never communicated that. And when they noticed that it was not part of the automatic update, they pulled it instead of just telling people the commandline.
Like to hide, that they did not know how their own updater was supposed to work.
Of course there is a chance that the EFI ME Updater has instability on top of the chaos. But that would only further illustrate how bad the “release” is.
Same as that they tried to sneakily release the 3.08 Windows installer. And ignored all comments that it was the wrong installer and then silently, without ever mentioning it, swapped the link out. No explanation, no note that the file has changed and what it solves. Nothing.
They still haven’t managed to simply read over their own release page and clean it up to make it look a little more professional by making it less contradictory or a tiny bit better structured.
All they have done with all of this, is convince me, that they are barely devoting any time to 12th gen and if they do, they have to rush so much it causes oversights.
Updated successfully. I decided to make a Windows To-Go on a 250GB expansion card in order to make the update a little easier and everything worked out just great. No issues. I did have a question, however.
I ordered the new 61wh battery and received an email (on Tuesday April 23) that said the BIOS update for the 12 Gen intel to use the new battery was “pending”; however, this post and the page for the update says that it should support the new battery now. I just wanted to confirm that that is actually the case in case anyone knows for sure.
Yes , support for 61Wh is included in 3.08 and it was also included when it was a beta release. However since the update was still in beta a week ago, they had to state that the support was pending as the release was not official and the product page did not get updated yet.
