edit: removed confrontational comment
A while ago I wrote an instruction about how to enable anti-rollback using Smokeless UMAF.
Disclaimer: NOT TESTED. The effort was a success. I’m wondering that maybe we can do the opposite as well. Disclaimer: NOT TESTED as I don’t have an FL16, use at your own risk.
Interesting… I know when it was in beta, I could roll back. I guess we can add the bug above to the 3.05 bios thread just in case it has something to do with it.
Ill cross-post it I guess.
Id say file a support ticket… but not sure they would be much help since the 240 ps isnt really “supported”
I think the 240W PS is technically supported as USB PD is standardized, so the problem might be the Delta electronics. If the low GPU wattage occurs on both 3.04 and 3.05, the problem is the Delta 240W PS. If it occurs only on 3.05, the problem is in Framework’s BIOS
Why spoiler the reason? They are explicitly saying that it’s not anti-user rights.
How do you ensure it’s the owner attempting to downgrade and not a boot kit (malware)? You should answer how to do that in a way that’s easy and able to be reasonably implemented before accusing Framework of being anti-user rights.
1 Like
Is there any documented incident that a malware managed to succeed an attack by downgrading a bios?
When I said “they”, I was speaking about the quote / post, which was not by a Framework staff member, just liked by one.
And if you can’t say how to prevent a boot kit (malware) from using rollback to nullify any user security, it’s just paranoid conspiracy theory in my opinion.
You claimed Framework is acting in bad faith, suggesting that they have another reasonable option.
1 Like
Is there any instances? zero. Are there instances of BIOS updates induced more problem than cannot be solved by the user because downgrade is blocked? here, here and here. It’s not a conspiracy theory.
It’s really that hard to gave the choice back to the users instead of taking the rights and claim that it’s “for your own good”?
You may wish to sacrifice all security. I do not, others do not, and some can not, due to company requirements or even government requirements such as HIPPA. Requiring reasonable actions to protect customer’s private medical history and other data. You not knowing of any instances of downgrades being used does not mean it doesn’t exist. And it’s not on me to show it does.
Again, you made the initial claim. That Framework has any other option.
The Burden of proof is on you to show how to reasonably implement downgrades without killing the security that many need to even be able to use a Framework.
1 Like
This is black and white thinking, not removing the option of downgrading BIOS doesn’t sacrifice all security. Also, FL16 was always able to downgrade BIOS until very recently, was all security sacrificed back then?
I don’t think that there are many people that are so paranoid that they don’t want to use(or as they say, not be able to) a Framework just because it’s possible to downgrade a BIOS.
Edit: I won’t engage further as in your opinion all security is in a single point.
Boot kits in firmware such as the BIOS is the most powerful / lowest level control an attacker can have. Nothing you can do will make your device secure.
In my opinion, yes. That’s why they needed to fix it.
But this is going nowhere and just filling the thread with back & forth. So I won’t engage further.
By having a hardware write protect switch on the BIOS? There used to be such a thing back in the days…
4 Likes
That’s the “another reasonable option”. Enable the hardware write protection, only turn off when upgrading or downgrading BIOS, then immediately turn back on.
1 Like
on a related note, hardware write protection is how chromebooks handle the user replacing the firmware with whatever. it’s what i would have expected with the ec design being borrowed from them.
while i’m certainly not assuming malice on the part of framework, i also believe being able to roll-back bios updates (or potentially installing an alternative, not that this an option yet) is an important feature, in the same bucket as right-to-repair.
3 Likes
Being able to roll back a change is an important safety item. I don’t have multiple identical Framework laptops, so I can’t test on one laptop first. If I update the BIOS and I discover a new problem, then what do I do? I won’t even know for sure if the problem is due to the BIOS update without being able to test the rollback.
From what I read here, blocking rollback is intended to increase security. Ironically, this is having the opposite effect for me: I am seeing that there is a BIOS update which supposedly fixes a security problem, but I hesitate to install the update for fear of causing a problem I will be unable to remedy.
I don’t see why we can’t have the best of both worlds. What about two update packages, one that locks and one that doesn’t? Then users can choose the one that is most suitable.
4 Likes