Samsung laptops can be NUKED by ANY OS – even Windows: new claim
'Guys, that's not what we meant by interoperability'
Ensure Ease of Recovery with Asigra’s Agentless Software
New Samsung laptops that destroyed themselves when booting Ubuntu Linux can be bricked by ANY operating system – including Windows – according to a top embedded developer.
Nebula programmer Matthew Garrett has shed new light on a baffling bug that renders shiny Sammy computers completely unusable by accident, and blamed the flaw on Samsung's firmware – the built-in software that powers up the machine.
The models at risk are the 300E5C, NP700Z5C, NP700Z7C, and 530U3C series of Sammy PC laptops.
At first the fault was tracked down to a Linux kernel hardware driver that was quickly disabled by developers to protect users' machines when booting open-source Linux. Greg Kroah-Hartman, who built the Samsung-laptop driver with Samsung's help, advised people to "blacklist" the kernel module to avoid any heartbreak.
But Garrett took to his personal blog on Friday night to urge people to boot their Samsung laptops in old-fashioned BIOS mode rather than the new UEFI standard, regardless of their OS choice, to avoid catastrophe. He said motherboard death could be caused by any code, not just Linux, that tries to write to the firmware's built-in storage area.
He wrote of the firmware-destroying flaw: "The information we now have indicates that there are other ways of triggering this."
According to Garrett, the disastrous bug is set off by writing too much information to the UEFI firmware's variables space, which causes a fatal error after a restart.
It is understood that Linux, when installing itself on the vulnerable laptops, triggers an exception and writes "too much" diagnostic data to the firmware's memory. According to the UEFI specification, it should not be possible to kill a computer by trying to storing too much information in the firmware but Sammy's hardware manages to do just that.
Microsoft's Windows could therefore potentially trip up just like Linux if it's not too careful: the open-source OS dumps 10KB of data into the firmware if the machine completely crashes. Windows 8 expects to be able to write 64KB into this variables storage area. But Garrett said he was able to brick his laptop by writing just 36KB to the Samsung UEFI from Windows.
"It also seems likely that it's possible for a user-space application to cause the same problem under Windows," Garrett added, providing a proof-of-concept program with source code to show he could ruin his machine from Windows. He said he ran the program "as an administrator under Windows and then rebooted the system. It never came back".
Garrett, who works as a power management, mobile and firmware developer on Linux, said more work is being done to figure out the full details. ®
COMMENTS
I'm not Eadon...
But I recall that any anti-Windows comment he may have posted on this particular topic was overwhelmed by a flood of 'AC's with such helpful suggestions as "Well if you will run freeware crap, you get what you pay for...".
No, Eadon may be a a rabid penguin-head, but at least he signs his own name! And after all, he's *our* rabid penguin-head...
Re: I'm not Eadon...
Not to mention that Eadon's anti-windows comments have no bearing on this, as the article states that Windows *can* and *does* brick a Samsung lappy the same as Linux. IIRC the 'AC's were also mostly MS shills saying the same thing about "freetards getting what they deserved".
So it is actually the shilltards who should be apologizing to *Eadon*. My my ... the irony...
Re: Why Linux could trigger a bug that Windows might not
"This I believe could differentiate why one system would trigger bugs but another would not. Linux devs might write code and functionality that remain in the overall scope of the Linux way of thinking whereas MS Devs would simply ignore the existance of such and such an API because it does not fall into the scope of their requirements.."
..or it could be that someone wrote some code that conformed to the UEFI spec and because the firmware had bugs it bricked the laptops. That someone in the first instance was a Linux developer writing a kernel driver but, as appears to have been demonstrated, the choice of OS is irrelevant and the code can come from user-space (so any developer, not necessarily one from the institution responsible for the OS, could potentially trigger this).
I'm not sure some strange theory about how and why certain organisations write the code they do is particularly useful in this instance.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring
