Booting Linux instead of Windows 8 bricks some Samsung laptops

A kernel fix is on the way, but the faulty laptop driver is still in use.

Linux desktop enthusiasts have been booting their operating systems of choice on computers designed for Windows for years now. Windows 8, however, poses some unique challenges because systems with the "Designed for Windows 8" logo must ship with the UEFI secure boot mechanism enabled. That prevents the booting of OSes lacking a signature from a trusted Certificate Authority.

The Linux Foundation came up with a general fix that can address a variety of systems, and there are also solutions designed for specific types of computers. It turns out one of those fixes didn't quite work, and now numerous Samsung laptops are being bricked—that is, rendered unusable and unfixable without a motherboard replacement—when users boot Linux using UEFI.

(Correction: The problem isn't actually related to the secure boot mechanism. A reader pointed us to a post by Linux developer Matthew Garrett, who notes that "Samsung apparently changed their platform interface when they moved to UEFI, but didn't actually do anything to prevent old drivers from breaking things." The good news is "some of the machines that are affected by this predate Secure Boot, so at least it's not a Secure Boot bug.")

Whatever the cause, it is a problem that has resulted in some laptops becoming unusable. "According to current understanding, the problem affects at least the following Samsung laptops: NP300E5C, NP530U3C, NP700Z3C, NP700Z5C, NP700Z7C and NP900X4C," The H reported. "The problem came to general attention as the result of a bug report which stated that laptops were bricked after just a single attempt to boot Ubuntu 12.04 or 12.10 in UEFI mode. The problem is also likely to occur with other Linux distributions, since they also include the samsung-laptop driver, which appears to trigger some sort of bug in the UEFI firmware." The H noted one case in which "Samsung repaired the laptop, which was under warranty, by replacing the motherboard."

Those model numbers refer to Samsung Series 3, Series 5, Series 7, and Series 9 laptops. Linux kernel maintainer Greg Kroah-Hartman explained on Google+ that the culprit is a laptop driver he built—but he built it using code Samsung gave him.

"Hm, who would have thought that just randomly poking memory of a laptop would brick it," Kroah-Hartman wrote. "Long ago Samsung told me that it was just fine to be doing this, and that there would not be any problems (I based the samsung-laptop driver on code that Samsung themselves gave me.) Turns out, it wasn't true, which is sad. Yes, the real solution is to fix the BIOS. If you have this hardware, just blacklist the samsung-laptop driver and all should be fine."

Kroah-Hartman himself was able to run Ubuntu on one of the Samsung laptops without any problems. A bug report shows that it is a problem for some users, though, with one saying, "the boot process panics and throws a machine check exception."

Fortunately, help is on the way. As The H notes, "[Linux creator] Linus Torvalds merged two changes into the main Linux development tree which mean that the samsung-laptop kernel driver will no longer be activated when Linux is booted via UEFI." The change was made yesterday and should result in updates to users "over the next few weeks." Until patches arrive, "users should always use the UEFI firmware's Compatibility Support Module (CSM), which emulates a BIOS mode, when booting on affected laptops."

We sent an inquiry to Samsung to ask if the company can offer any fix, and will provide an update if we get one.

Promoted Comments

According to another article that I saw, clearing the NVRAM supposedly addresses this issue.

"Update: It appears the problem stems from NVRAM corruption. Removing power, opening the laptop up, and disconnecting the CMOS battery appears like it will clear the problem, but that's a pretty serious set of steps to take for most laptops."

Windows 8, however, poses some unique challenges because systems with the "Designed for Windows 8" logo must ship with the UEFI secure boot mechanism enabled. That prevents the booting of OSes lacking a signature from a trusted Certificate Authority.

Doesn't that Windows 8 logo certification require that the system have a switch to turn off secure boot? I'm not seeing what the challenge is. Am I missing something?

Short version: this isn't a secure boot problem, it's been reproduced without UEFI. This is a case of crappy harware that violates their own crappy practices, when standard implementations exist that could have prevented the issue. Sounds like abgood reason to return that Samsung laptop for something better.

I don't see the problem here... this is exactly what the system was suppose to do. Why on earth did they think you can clean boot to any other OS? If Samsung said yes this is possible then they themselves were just contradicting the very nature of Secure Boot. It wouldn't be secure if I could just boot to Linux and run that $300 dollar software to defeat BitLocker?

Short version: this isn't a secure boot problem, it's been reproduced without UEFI. This is a case of crappy harware that violates their own crappy practices, when standard implementations exist that could have prevented the issue. Sounds like abgood reason to return that Samsung laptop for something better.

Thanks for that. It made much more sense than the beginning of the article. The mention of Windows 8 in the article isn't needed.

While the kernel driver should absolutely be fixed to prevent this problem, it is wrong to say that it is the fault of kernel driver. Hardware should never become bricked because of a bad software command. If it can then that hardware is faulty, period.

This isn't the first time that Samsung has done this either. They have had similar problems when they screwed up their eMMC firmware. Google made them fix it in firmware for the Galaxy Nexus, but they continued to ship other devices with bad firmware and drivers for long after the problem and fix was known. See this post for more info.

I don't see the problem here... this is exactly what the system was suppose to do. Why on earth did they think you can clean boot to any other OS? If Samsung said yes this is possible then they themselves were just contradicting the very nature of Secure Boot. It wouldn't be secure if I could just boot to Linux and run that $300 dollar software to defeat BitLocker?

Edit: Hey don't hate on the messenger.. just don't buy a laptop with secureboot!

Isn't not that we hate the messenger, it's that the messenger is speaking nonsense.

I don't see the problem here... this is exactly what the system was suppose to do. Why on earth did they think you can clean boot to any other OS?...

Perhaps a hypothetical will help you see the problem. I sneak into your office and attempt to boot your laptop with my Knoppix disk to steal your secrets. Doesn't work. Good. Secure Boot prevented me from stealing your stuff.

You return from lunch and power up your laptop. Doesn't work. Bad! I hope you have really good backups because your laptop is bricked.

I don't see the problem here... this is exactly what the system was suppose to do. Why on earth did they think you can clean boot to any other OS? If Samsung said yes this is possible then they themselves were just contradicting the very nature of Secure Boot. It wouldn't be secure if I could just boot to Linux and run that $300 dollar software to defeat BitLocker?

Edit: Hey don't hate on the messenger.. just don't buy a laptop with secureboot!

Isn't not that we hate the messenger, it's that the messenger is speaking nonsense.

Is the whole point not to allow a Clean OS? How is that secure if that were at all possible?

[quote"wiki"]The UEFI 2.2 specification adds a protocol known as Secure boot, which can secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature. [/quote]

I don't see the problem here... this is exactly what the system was suppose to do.

I find it hard to believe (or even imagine) that the intended effect of attempting to boot another OS was the irreversible destruction of the logic board.

I think the intended effect might have been to prevent booting. To the extent that corrupting the motherboard's firmware and putting it into an unbootable state prevents booting, I suppose that goal is achieved. But part of that goal, I would think, would entail allowing the computer afterward to boot an approved OS successfully. Without a working motherboard, that aspect of this goal is plainly not achieved.

According to another article that I saw, clearing the NVRAM supposedly addresses this issue.

"Update: It appears the problem stems from NVRAM corruption. Removing power, opening the laptop up, and disconnecting the CMOS battery appears like it will clear the problem, but that's a pretty serious set of steps to take for most laptops."

I don't see the problem here... this is exactly what the system was suppose to do.

I find it hard to believe (or even imagine) that the intended effect of attempting to boot another OS was the irreversible destruction of the logic board.

Really, so bricking wasn't going to happen when the bios itself was damaged?

Bricking can certainly happen when firmware is damaged, but damaged firmware and the resultant bricking, by which we mean rendering the machine both unusable and unrepairable, is not by any means the intended effect of Secure Boot. Don't be silly.

Can we define the usage of the word "brick". To me, bricking means short of replacing chips, it is dead. Having a boot option that results in a kernel panic is not a brick. It is a kernel panic. As you can still boot from other media, or an alternate hard drive.

The caveat is that this is simply considered a reference implementation and BIOS vendors like Insyde, Phoenix, and American Megatrends don't participate. They have their own implementations that are not open source, and those are what end up on most platforms today.

This is highly annoying because they often exhibit divergent behavior, have bugs introduced by the system vendor, and omit useful protocols. I'd be much happier if UEFI implementations on motherboards utilized the reference builds (and if you're really into it, you can swap out some vendor drivers with Tianocore versions) but I highly doubt Phoenix and AMI are going to change anything about how they've done business over the last 25+ years.

Scorp1us wrote:

Can we define the usage of the word "brick". To me, bricking means short of replacing chips, it is dead. Having a boot option that results in a kernel panic is not a brick. It is a kernel panic. As you can still boot from other media, or an alternate hard drive.

The issue at hand readily bricks the Samsung units, as the only way to recover for most people is to swap out the system, others can clear the NVRAM and continue.

WaveRunner wrote:

What was the BIOS suppose to do after it found itself corrupted? Just randomly run anyways at level zero? Don't be silly!

The BIOS itself was not corrupted. The NVRAM store was. When the BIOS encountered a corrupted NVRAM (which is not where the BIOS is stored) it should have reset the NVRAM and gone back to defaults, not crashed.

I don't see the problem here... this is exactly what the system was suppose to do.

I find it hard to believe (or even imagine) that the intended effect of attempting to boot another OS was the irreversible destruction of the logic board.

Really, so bricking wasn't going to happen when the bios itself was damaged?

Bricking can certainly happen when firmware is damaged, but damaged firmware and the resultant bricking, by which we mean rendering the machine both unusable and unrepairable, is not by any means the intended effect of Secure Boot. Don't be silly.

yes but a program randomly poking around did. What was the BIOS suppose to do after it found itself corrupted? Just randomly run anyways at level zero? Don't be silly!

A program run on a computer is supposed to be unable to modify the BIOS. Only the BIOS can modify the BIOS. You obviously have little to no programming experience. Poking around the BIOS means sending queries for information of some type, to test feature support. it doesn't mean stabbing with a sword. If poking around the BIOS normally resulted in a bricked laptop, all laptops would be bricked by some piece of stupid malware, because malware authors would love to be able to do that. You do understand the concept of bricking, right?

It should be implemented as an open source project. Having these systems hard coded into a MoBo is somewhat anti-competitive given their closed nature and now clear ability to disrupt other OS's.

That doesn't make any sense. What does open source have to do with UEFI? Lots of motherboards use UEFI for years, however the problem here is a feature called Secure Boot and how Samgsun screw-up their their motherboard implementation.

Since you are talking about security it obviously NEEDS to be implemented on the motherboard, otherwise what's the point? If I think that my laptop is nicely protect and someone can come-along with a Linux LiveCD and access my data, then the feature would be entirely pointless.

Also, It's not in the least anti-competitive because Microsoft mandates that you have to be able to turn-off (and windows 8 will run just fine without it). Samsung screw-ed up because nothing should allow you to corrupt the NVRAM so that you can't boot computer if software attempts unauthorized access.

According to another article that I saw, clearing the NVRAM supposedly addresses this issue.

"Update: It appears the problem stems from NVRAM corruption. Removing power, opening the laptop up, and disconnecting the CMOS battery appears like it will clear the problem, but that's a pretty serious set of steps to take for most laptops."

Taken with Matthew Garett's comments, it sounds like the Samsung driver wanted to write to NVRAM on the flash part. The flash is often set to 'read only' before boot and can only be unlocked when the system is in SMM. writing to NVRAM requires writing to flash so the system would need to enter SMM to do this. But there is no standard interface, the concept evolved separately with each IBV, OEM, and ODM. It's a really good illustration of why UEFI is a good idea. The GetVariable() and SetVariable() runtime services exist to standardize access to NVRAM.So please remember that UEFI exists to solve a lot of problems in BIOS that have been hidden from anyone not working at these extremely low levels. There is a standards body behind it which should make shenanigans harder to pull off.

According to another article that I saw, clearing the NVRAM supposedly addresses this issue.

"Update: It appears the problem stems from NVRAM corruption. Removing power, opening the laptop up, and disconnecting the CMOS battery appears like it will clear the problem, but that's a pretty serious set of steps to take for most laptops."

Also, It's not in the least anti-competitive because Microsoft mandates that you have to be able to turn-off (and windows 8 will run just fine without it). Samsung screw-ed up because nothing should allow you to corrupt the NVRAM so that you can't boot computer if software attempts unauthorized access.

Don't stand in front of the stampeding anti-Microsoft crowd, you're likely to get injured.

I am certainly enjoying downvoting all your and waverunner's ignorant and asinine posts.

I love how all the Linux fans are extrapolating the article to blame Microsoft for anti-competitive practices and UEFI being horrible with presumably not ever finishing the title.

I don't see anyone in the comments blaming MS, and rightfully so. Other than the clickbait-ish headline, who here is blaming MS? This is very clearly a Samsung screwup and every commenter who actually understands the tech involved appears to have recognized that immediately.