The mention of UEFI in this context likely means they are thinking of a deletion recursing through sysfs and by extension deleting all visible UEFI variables which, in some firmware editions and versions, causes it not to be able to get through post or into the setup menu.
I vaguely recall this and the general issue was very bad firmware design, but it was possible to make it impossible to even reinstall a system. If you were industrious in windows you could have done the same thing, so malware under windows could also brick such platforms.
Of course rm has more safeguards on it so you have to pass more flags and really really be asking it to try to screw things up.
So, I would assume the firmware gave write access to a part of permanent memory, critical to starting the system.
I feel like that would be someone like me, thinking of it as a feature and giving the possible values for those variables in the readme. And of course, who reads the readme even though it says “READ ME”?
UEFI defines a structured way to have data shared with OS as read write variables, including the ability to create, modify, and delete variables that UEFI can see.
However, some firmware used this facility to store values and then their code assumed the variables would always be there. The code would then crash when it goes to read a deleted variable and not know what to do. The thing is deleting those variables per spec is a perfectly valid the due the OS to do, but firmware was buggy and the bugs not caught because normally OS would not bother those variables except for a few standard popular ones, like boot order.
So flashing the firmware would “solve” the issue? As in, it should rewrite the variables missing (and everything else), making the hardware usable again?
Generally speaking, these platforms are not flashable unless they can boot a flash utility, assuming that whatever prior firmware is running is at least in good enough shape to boot to an update environment.
There are designs to be robust and accessible even in the face of all this, but relatively rare, effectively unheard of in laptop market. Even some of those emergency recovery environments may be more limited than you would like to repair this sort of thing.
The mention of UEFI in this context likely means they are thinking of a deletion recursing through sysfs and by extension deleting all visible UEFI variables which, in some firmware editions and versions, causes it not to be able to get through post or into the setup menu.
I vaguely recall this and the general issue was very bad firmware design, but it was possible to make it impossible to even reinstall a system. If you were industrious in windows you could have done the same thing, so malware under windows could also brick such platforms.
Of course rm has more safeguards on it so you have to pass more flags and really really be asking it to try to screw things up.
Nice to know.
So, I would assume the firmware gave write access to a part of permanent memory, critical to starting the system.
I feel like that would be someone like me, thinking of it as a feature and giving the possible values for those variables in the readme. And of course, who reads the readme even though it says “READ ME”?
UEFI defines a structured way to have data shared with OS as read write variables, including the ability to create, modify, and delete variables that UEFI can see.
However, some firmware used this facility to store values and then their code assumed the variables would always be there. The code would then crash when it goes to read a deleted variable and not know what to do. The thing is deleting those variables per spec is a perfectly valid the due the OS to do, but firmware was buggy and the bugs not caught because normally OS would not bother those variables except for a few standard popular ones, like boot order.
I see, in that case, that would not be someone like me :P as I tend to care about specifications.
This is a really useful explanation for someone who doesn’t know about the UEFI spec.
So flashing the firmware would “solve” the issue? As in, it should rewrite the variables missing (and everything else), making the hardware usable again?
Generally speaking, these platforms are not flashable unless they can boot a flash utility, assuming that whatever prior firmware is running is at least in good enough shape to boot to an update environment.
There are designs to be robust and accessible even in the face of all this, but relatively rare, effectively unheard of in laptop market. Even some of those emergency recovery environments may be more limited than you would like to repair this sort of thing.