Booting Linux using UEFI can brick Samsung laptops

jai134 · 2013-02-20 18:14:19

I have had Arch installed on my 900x4c booting with refind and uefi. No panics and no brick. I am running windows now because of my printer, a Brother that is not supported with any aur-package. I didn't know about this bug and I have obviously not noticed anything. Have I been just lucky or is this bug not a problem anymore? I like Arch and I would really like to run it on my laptop as soonas I can make my printer work with it.
Sorry if it is a stupid question but I really would like to know if it is safe. First arch install I did was at new year. Dont know which kernelversion I installed.

blackout23 · 2013-02-20 18:28:21

I read all the Wiki pages about UEFI and still haven't figured out why I should prefer it over my BIOS boot.
My motherboard is fairly modern Intel Z68 Motherboard for Sandybrige CPUs and has UEFI it looks like a pain in the ass to set up and for what benefit?
Right now I chainload my Windows 7 (just as a gaming console) with Syslinux and it works.

Last edited by blackout23 (2013-02-20 18:29:51)

olive · 2013-02-20 21:18:55

blackout23 wrote:

I read all the Wiki pages about UEFI and still haven't figured out why I should prefer it over my BIOS boot.
My motherboard is fairly modern Intel Z68 Motherboard for Sandybrige CPUs and has UEFI it looks like a pain in the ass to set up and for what benefit?
Right now I chainload my Windows 7 (just as a gaming console) with Syslinux and it works.

The only benefit I see is that in the long run, BIOS will (most probably) be dropped. So you can learn now what to do in the future. You won't probably have any benefit of putting your system in UEFI right now. The more general question as to whether UEFI is good or bad. Linus didn't like it (see for example: http://kerneltrap.org/node/6884). I am not a developer and I can't make a definitive judgement. But a lot of so called advantages of UEFI does not seem to make sense for me. I would opt to keep the firmware minimal, because it is not free, not easily upgradable and manufacturer specific. Instead of providing the ability to write scripts, I think better to provide the minimum necessary to boot something that allows to write scripts (like in BIOS), if you want to.

Last edited by olive (2013-02-20 21:24:54)

srs5694 · 2013-02-21 19:27:45

jai134 wrote:

I have had Arch installed on my 900x4c booting with refind and uefi. No panics and no brick. I am running windows now because of my printer, a Brother that is not supported with any aur-package.

Because your problem is completely unrelated to EFI, you should really start a new thread about it. People who read this thread are interested in UEFI issues, not (necessarily) about printer issues.

blackout23 wrote:

read all the Wiki pages about UEFI and still haven't figured out why I should prefer it over my BIOS boot.

Right now, the practical advantages of EFI are pretty minor:

Faster boot times on some (not all) hardware.
Different boot manager and boot loader options -- if you really like rEFInd or gummiboot, EFI is an advantage.
The ability to maintain multiple boot loaders as files in a filesystem, rather than using a convoluted chainloading mechanism that involves reading unlabelled binary blobs from MBRs or PBRs.
On very new hardware, Secure Boot can provide some protection against boot-time malware; but not all EFIs support Secure Boot, and it requires extra effort to set up, especially on Arch, which doesn't explicitly support it.
Access to EFI NVRAM storage in the OS, which can help with debugging certain types of kernel crashes.

There may be more, but these are the ones that spring to mind. Also, the boot loader differences can be subtle and complex, so you could legitimately break the two I've mentioned into several more that are intertwined.

olive wrote:

I would opt to keep the firmware minimal, because it is not free, not easily upgradable and manufacturer specific.

Actually, UEFI is open source software -- the reference implementation (TianoCore) is distributed under a BSD license. You can obtain it here. I've heard that it's possible to combine that implementation with CoreBoot to get a working firmware, but I've not looked into the details. This is actually more open than BIOS; most BIOSes are based on highly proprietary code, although SeaBIOS is an open source implementation. Years ago there were companies that sold replacement BIOSes for popular motherboards, but I've not heard of such things recently, except for CoreBoot or CoreBoot + SeaBIOS, so I don't think that a system with a UEFI is any more or less flexible in this respect than a BIOS from, say, three years ago.

That said, computer manufacturers make their own changes to the TianoCore reference implementation, and these changes tend to be proprietary. Thus, the firmware you get in your computer is almost certain to be proprietary whether it's an old-style BIOS or a new UEFI. The UEFI will be based on the open-source TianoCore, though, at least in part. (There's likely to be some proprietary hardware initialization code and probably some proprietary user interface code.)

jai134 · 2013-02-21 20:00:33

Sorry to be unclear. The printer-issue was an explanation why I dont run Arch at the moment. My question is: Is it safe to install Arch again? I have had Arch up and running withour any kernel panics and my laptop is absolutely no brick.

jasonwryan · 2013-02-21 20:05:05

jai134 wrote:

Is it safe to install Arch again? I have had Arch up and running withour any kernel panics and my laptop is absolutely no brick.

As is mine. I do blacklist the samsung_laptop module just to make sure (as I said at the start of the thread)...

Jristz · 2013-02-21 20:05:52

jai134 wrote:

Sorry to be unclear. The printer-issue was an explanation why I dont run Arch at the moment. My question is: Is it safe to install Arch again? I have had Arch up and running withour any kernel panics and my laptop is absolutely no brick.

I read report that the brick can happen in Windows too, the most secure is usong BIOS at the time for Sansung machines

olive · 2013-02-21 20:09:54

srs5694 wrote:

Actually, UEFI is open source software -- the reference implementation (TianoCore) is distributed under a BSD license. You can obtain it here. I've heard that it's possible to combine that implementation with CoreBoot to get a working firmware, but I've not looked into the details. This is actually more open than BIOS; most BIOSes are based on highly proprietary code, although SeaBIOS is an open source implementation. Years ago there were companies that sold replacement BIOSes for popular motherboards, but I've not heard of such things recently, except for CoreBoot or CoreBoot + SeaBIOS, so I don't think that a system with a UEFI is any more or less flexible in this respect than a BIOS from, say, three years ago.
That said, computer manufacturers make their own changes to the TianoCore reference implementation, and these changes tend to be proprietary. Thus, the firmware you get in your computer is almost certain to be proprietary whether it's an old-style BIOS or a new UEFI. The UEFI will be based on the open-source TianoCore, though, at least in part. (There's likely to be some proprietary hardware initialization code and probably some proprietary user interface code.)

Perhaps I express myself badly. You are right that UEFI itself is not more closed than Bios and perhaps more open. But upgrading it is hardware specific. You can use coreboot if your motherboard support it and accept the risk of bricking your computer. My point is that it is best to keep the firmware minimal. All the features you present as advantages for UEFI could have existed as a third party module booted from the disk in Bios mode (actually grub or syslinux provides most of the features you describe, chainloading from grub/syslinux is not more convoluted than chainloading from UEFI). If this what was made you could have simply updated this module with pacman -Syu with no risk to brick your system if you had updated a version of this module that is buggy (and pacman -Syu is easier than reflashing the motherboard with a new version of coreboot). Bios itself is very old and I do not defend the Bios per se but well the concept of keeping the firmware minimal. As for the protection of Secure boot, I don't believe it. Hackers will find a way to exploit security holes in signed drivers or a private key will eventually leak. Look how it is easy to jailbreak an iPad that use the same concept of "secure boot" (an iPad boot only something signed by Apple, officially).

Last edited by olive (2013-02-21 20:58:16)

jai134 · 2013-02-21 21:40:33

Understand more now. Thankyou for the replies.

srs5694 · 2013-02-22 00:07:14

jai134 wrote:

Sorry to be unclear. The printer-issue was an explanation why I dont run Arch at the moment. My question is: Is it safe to install Arch again? I have had Arch up and running withour any kernel panics and my laptop is absolutely no brick.

I don't recommend booting any OS on a Samsung in EFI mode, since the bug has been shown to affect Windows, and theoretically any OS. See Matthew Garrett's blog post on the subject for details. Although the most common cause of bricking has been dealt with, the bug can be triggered by perfectly legitimate activity -- activity that should not be curtailed, at least not generally. The easiest way to ensure that you don't run into this problem is to boot in BIOS mode.

olive wrote:

But upgrading it is hardware specific. You can use coreboot if your motherboard support it and accept the risk of bricking your computer. My point is that it is best to keep the firmware minimal.

Upgrading any firmware is hardware-specific. CoreBoot must be built for specific chipsets, too. If you prefer to use a minimal firmware, I won't try to convince you otherwise; but for most users today, CoreBoot isn't an option. At best, you've got a choice of BIOS (on older hardware or by using BIOS compatibility in a UEFI) or EFI.

olive wrote:

chainloading from grub/syslinux is not more convoluted than chainloading from UEFI

Although it's possible to set up a relatively sane chainloading system using a combination of GRUB (or SYSLINUX) and MBR boot code stored as files somewhere, that's not the way it's generally done. You're generally locked into one boot path per OS, via its boot loader on a partition, and changing boot loaders involves writing code blindly to the boot sector. The only way to identify what you're using after that point is to do a raw read of the hard disk's boot sector and search for magic values or compare hashes or CRCs against values in a table. With EFI, by contrast, you've got descriptive filenames and entries in the NVRAM that (ideally) clearly identify what you're booting, and updating the boot loader involves writing files in a filesystem. That's much cleaner than the BIOS approach. At best, with BIOS, if everybody agreed to use GRUB (or something else with some similar features), you could implement something that resembles the EFI approach. If you think you could convince everybody to use GRUB, though, I've got a bridge to sell you.... ;-)

olive · 2013-02-22 08:10:32

srs5694 wrote:

Upgrading any firmware is hardware-specific. CoreBoot must be built for specific chipsets, too. If you prefer to use a minimal firmware, I won't try to convince you otherwise; but for most users today, CoreBoot isn't an option. At best, you've got a choice of BIOS (on older hardware or by using BIOS compatibility in a UEFI) or EFI.

Yes but if the firmawre is the minimum necessary to boot the machine, you won't need to upgrade it as long as you can boot the system. Once it is booted it is not used anymore. If the firmware is so buggy that it does not even boot, the machine wouldn't have been sold (or you can return it under warranty). Of course you can imagine borderline cases, but that's the idea. This is what I would have thought to be the ideal solution. Now every machine will be shipped with UEFI and there will be no real viable option than to live with it. If we can continue to use a computer without using it (after the system is booted), we can simply ignore it (except for starting the system) and live with it.

srs5694 wrote:

Although it's possible to set up a relatively sane chainloading [...] that's not the way it's generally done.

What you are saying it is that it is good to force, via a program implemented in hardware (UEFI), to use a system the way you find it best. That's an idea I can't agree with and completely contradictory to the free software philosophy (and of Archlinux which is to build the system the way you want). If you can boot, then boot the module that fulfills your expectation.

Last edited by olive (2013-02-22 08:16:06)

srs5694 · 2013-02-22 17:23:32

olive wrote:

srs5694 wrote:
Although it's possible to set up a relatively sane chainloading [...] that's not the way it's generally done.
What you are saying it is that it is good to force, via a program implemented in hardware (UEFI), to use a system the way you find it best. That's an idea I can't agree with and completely contradictory to the free software philosophy (and of Archlinux which is to build the system the way you want). If you can boot, then boot the module that fulfills your expectation.

No, that's not what I'm saying! I'm saying that BIOS boot loading is a mess, that UEFI boot loading is (at least theoretically) less of a mess, and that as a practical matter what you or I prefer is irrelevant because the decision of what firmware to include in a computer is being made by manufacturers, not by you and not by me. I'm not forcing EFI on anybody, nor would I do so if I had the choice, and I respectfully request that you stop putting words in my mouth.

Just to be clear: UEFI has serious problems, and if I could design something to take its place, it would probably be more to your liking. Living in the real world, though, we're stuck with UEFI, and it does have its advantages over BIOS. Denying those advantages is pointless, just as is denying UEFI's flaws, or the flaws of specific UEFI implementations, including (to bring this somewhat back on-topic) the bug in Samsung's implementation that can brick a computer.

jai134 · 2013-02-22 22:34:42

Is this bug something that comes after a period of time or is it something I will notice immediatly after a fresh install? I have a new install of arch and my laptop is running flawlessly. I read the blog linked to by srs5694 and I am sorry to say that I didn't understand it. Thinking of this: " it turns out that some Samsung laptops will fail to boot if too much of the variable storage space is used".

jasonwryan · 2013-02-22 23:18:34

A fix has been merged: http://www.h-online.com/open/news/item/ … 95332.html

srs5694 · 2013-02-23 00:00:27

jai134 wrote:

Is this bug something that comes after a period of time or is it something I will notice immediatly after a fresh install? I have a new install of arch and my laptop is running flawlessly. I read the blog linked to by srs5694 and I am sorry to say that I didn't understand it. Thinking of this: " it turns out that some Samsung laptops will fail to boot if too much of the variable storage space is used".

It could occur immediately or after some time. The sentence you've quoted hints at why -- the EFI variable storage can be used by a number of tools, and the amount of that storage space that's used can vary from one use to another. Thus, once the critical threshold is exceeded, bang! -- you've got a brick. Unless you're Matthew Garrett or somebody else doing development on that level, you probably don't know what might use this EFI variable storage, and even then, it's risky, since one of the things that can use it is the kernel when it crashes. A bricking can occur because of a user-mode program or even under Windows, too. Thus, it is not safe to boot a recent Samsung laptop in EFI mode -- at least not until Samsung (or conceivably, but improbably, somebody else) issues a firmware with a fix and you've applied that update.

jasonwryan wrote:

A fix has been merged: http://www.h-online.com/open/news/item/ … 95332.html

Unfortunately, that's not a perfect fix. It does fix the most obvious and immediate cause of Samsung bricks, and so will help in the short term for many people. Running like this is like playing Russian Roulette with your computer, though, for the reasons described in Matthew Garrett's blog post on the subject. This is particularly worrisome because you might go for a year or two without problems, and then brick your computer. That might cost you real money for repairs if the bricking occurs once the warranty has expired.

jasonwryan · 2013-02-23 01:38:50

srs5694 wrote:

jasonwryan wrote:
A fix has been merged: http://www.h-online.com/open/news/item/ … 95332.html
Unfortunately, that's not a perfect fix. It does fix the most obvious and immediate cause of Samsung bricks, and so will help in the short term for many people. Running like this is like playing Russian Roulette with your computer, though, for the reasons described in Matthew Garrett's blog post on the subject. This is particularly worrisome because you might go for a year or two without problems, and then brick your computer. That might cost you real money for repairs if the bricking occurs once the warranty has expired.

This is true. But is like much in the rest of life; the risk of catastrophic failure is omnipresent...

srs5694 · 2013-02-23 18:57:28

jasonwryan wrote:

This is true. But is like much in the rest of life; the risk of catastrophic failure is omnipresent...

No, it's worse. There are very few programs that run the risk of bricking a computer in day-to-day use -- only tools that are designed to flash the EEPROM are likely to do that. With the Samsung UEFI bug, OTOH, the range of programs that can cause problems goes up, especially since one possible route to bricking is a simple kernel crash. Granted, kernel crashes are rare, but they aren't unheard-of, and a kernel crash causing a problem that requires physical service to the computer is, IMHO, unacceptable. The same kernel crash, if it were to occur with the computer booted in BIOS mode, will not brick the computer.

Put another way: The risk of bricking the computer is higher when run in UEFI mode than when run in BIOS mode. I grant that switching Windows from UEFI mode to BIOS mode is a pain, but aside from that, there's very little to justify taking the risk.

jasonwryan · 2013-02-23 20:08:12

You misunderstood me; my point was that, in the grand scheme, a bricked laptop is of (relatively) little consequence--ie., if that was the worst that was going to happen to me, I'd be grateful.

blackout23 · 2013-02-24 19:52:50

srs5694 wrote:

blackout23 wrote:
read all the Wiki pages about UEFI and still haven't figured out why I should prefer it over my BIOS boot.
Right now, the practical advantages of EFI are pretty minor:
Faster boot times on some (not all) hardware.
Different boot manager and boot loader options -- if you really like rEFInd or gummiboot, EFI is an advantage.
The ability to maintain multiple boot loaders as files in a filesystem, rather than using a convoluted chainloading mechanism that involves reading unlabelled binary blobs from MBRs or PBRs.
On very new hardware, Secure Boot can provide some protection against boot-time malware; but not all EFIs support Secure Boot, and it requires extra effort to set up, especially on Arch, which doesn't explicitly support it.
Access to EFI NVRAM storage in the OS, which can help with debugging certain types of kernel crashes.
There may be more, but these are the ones that spring to mind. Also, the boot loader differences can be subtle and complex, so you could legitimately break the two I've mentioned into several more that are intertwined.

Thank you for this detailed explanation. I'm going to set up my PC with UEFI and rEFInd and dual boot Window 7 and Arch from GPT partitions.
Looks a nice way to spend a rainy weekend.

Last edited by blackout23 (2013-02-24 19:56:46)

ngoonee · 2013-02-25 11:36:25

A bit late, but a user brought to my attention that this doesn't belong in Arch Discussion. Moving to Kernel and Hardware.

nomorewindows · 2013-02-25 22:21:53

Even though UEFI and BIOS are separate implementations, the old "secure boot" was preventing boot sector writes, at least in DOS. Would it do the job today? Probably not. If everything else was using UEFI for the longest time, the implementation is still related to architecture? Maybe this UEFI is a way of mass producing motherboards, just upload the architecture specific image and it's ready to go. The BIOS implementation has been somewhat redundant. The BIOS has to load the devices, then load any device BIOS and hook to one of the interrupt vectors. Then read the disk, then the operating system has to initialize the devices all over again for it using them. But if the BIOS is messed up or the device isn't there, the operating system can't tell the difference. Of course the operating system may do something totally different than what BIOS does. I'm assuming that UEFI is going to pick the devices the same way that the operating system sees them.

nomorewindows · 2013-02-27 17:30:12

Reading about the Macintosh's having problems being able to boot anything except proprietary Apple OS, was the reason why they created the openfirmware and EFI was so that they could boot something else. I don't think that this was ever a problem with IBM PC and compatibles. So now Microsoft is going to tie the UEFI to SecureBoot so that only Windows can be booted on a particular machine. This seems so contrary to purpose.

65kid · 2013-03-03 11:31:19

oh for f*cks sake, I think I just found yet another firmware bug on my 900x4d.

A few days ago I tried out the new gummiboot setup tool (currently in [testing]). It automatically copies the gummiboot binary to /boot/efi/ and creates an entry in the EFI bootloader. So far so good, this worked as expected. Then I decided to remove my old gummiboot entry that I created manually before.
So I did:

efibootmgr -B -b <BootID>

... kernel panic... oh well...
Luckily, the machine still booted and the gummiboot entry I wanted to remove was actually gone. I also read that efibootmgr doesn't support the new efivars interface from kernel 3.8 and thought that this may be the cause, so I didn't investigate further.

Now, a few days later I try to access the BIOS setup. Well here is the problem - I can't. The F2 key doesn't do anything. I can still press F10 for the boot menu and when you press Tab from there, you get in another submenu where usually "Setup" is listed - it isn't anymore. I assume that my efibootmgr command somehow deleted the Setup entry as well and now I'm kind of screwed. Already opened it up and unplugged the battery, didn't help either. Well, shit...

Could anybody here with a Samsung laptop give me the output of the following so I can confirm there is supposed to be a "Setup" entry?

sudo efibootmgr -v

Last edited by 65kid (2013-03-04 09:18:09)

nomorewindows · 2013-03-03 13:38:22

65kid wrote:

oh for f*cks sake, I think I just found yet another firmware bug on my 900x4c.
A few days ago I tried out the new gummiboot setup tool (currently in [testing]). It automatically copies the gummiboot binary and creates an entry in the EFI bootloader. So far so good, this worked as expected. Then I decided to remove my old gummiboot entry that I created manually before.
So I did:
efibootmgr -B -b <BootID>
... kernel panic... oh well...
Luckily, the machine still booted and the gummiboot entry I wanted to remove was actually gone. I also read that efibootmgr doesn't support the new efivars interface from kernel 3.8 and thought that this may be the cause, so I didn't investigate further.
Now, a few days later I try to access the BIOS setup. Well here is the problem - I can't. The F2 key doesn't do anything. I can still press F10 for the boot menu and when you press Tab from there, you get in another submenu where usually "Setup" is listed - it isn't anymore. I assume that my efibootmgr command somehow deleted the Setup entry as well and now I'm kind of screwed. Already opened it up and unplugged the battery, didn't help either. Well, shit...
Could anybody here with a Samsung laptop give me the output of the following so I can confirm there is supposed to be a "Setup" entry?
sudo efibootmgr -v

This looks like a job for PXE booting just to see what happens, even though you wouldn't try to run a mobile laptop this way on an everyday basis.
I'm just curious if you could PXE boot and related syslinux would get around the restrictions that UEFI is imposing on your machinery.

Oh...I did hear that certain UEFI implementations on certain laptops want to make sure that you have to boot into Windows 8, before being able to enter BIOS/UEFI setup. One person was so frustrated with it, that they explained the Windows tax being such a burden that even if you didn't ever want to use the Windows 8 pre-installed, that you practically had to agree to the licensing agreement of Windows 8, before you could even think about going into the setup screen. They tried rebooting and everything and it wouldn't allow them to go there.

Last edited by nomorewindows (2013-03-03 13:52:09)

65kid · 2013-03-03 14:12:56

I reset the BIOS settings by unplugging the CMOS battery. Unfortunately this didn't restore access to the BIOS Setup. Even more unfortunately: SecureBoot is now enabled again and booting from USB is disabled by default. And I can't change either of those things since I can't get into the BIOS.

In other words, I can't boot anything now which means the machine is basically bricked....

Arch Linux

#26 2013-02-20 18:14:19

Re: Booting Linux using UEFI can brick Samsung laptops

#27 2013-02-20 18:28:21

Re: Booting Linux using UEFI can brick Samsung laptops

#28 2013-02-20 21:18:55

Re: Booting Linux using UEFI can brick Samsung laptops

#29 2013-02-21 19:27:45

Re: Booting Linux using UEFI can brick Samsung laptops

#30 2013-02-21 20:00:33

Re: Booting Linux using UEFI can brick Samsung laptops

#31 2013-02-21 20:05:05

Re: Booting Linux using UEFI can brick Samsung laptops

#32 2013-02-21 20:05:52

Re: Booting Linux using UEFI can brick Samsung laptops

#33 2013-02-21 20:09:54

Re: Booting Linux using UEFI can brick Samsung laptops

#34 2013-02-21 21:40:33

Re: Booting Linux using UEFI can brick Samsung laptops

#35 2013-02-22 00:07:14

Re: Booting Linux using UEFI can brick Samsung laptops

#36 2013-02-22 08:10:32

Re: Booting Linux using UEFI can brick Samsung laptops

#37 2013-02-22 17:23:32

Re: Booting Linux using UEFI can brick Samsung laptops

#38 2013-02-22 22:34:42

Re: Booting Linux using UEFI can brick Samsung laptops

#39 2013-02-22 23:18:34

Re: Booting Linux using UEFI can brick Samsung laptops

#40 2013-02-23 00:00:27

Re: Booting Linux using UEFI can brick Samsung laptops

#41 2013-02-23 01:38:50

Re: Booting Linux using UEFI can brick Samsung laptops

#42 2013-02-23 18:57:28

Re: Booting Linux using UEFI can brick Samsung laptops

#43 2013-02-23 20:08:12

Re: Booting Linux using UEFI can brick Samsung laptops

#44 2013-02-24 19:52:50

Re: Booting Linux using UEFI can brick Samsung laptops

#45 2013-02-25 11:36:25

Re: Booting Linux using UEFI can brick Samsung laptops

#46 2013-02-25 22:21:53

Re: Booting Linux using UEFI can brick Samsung laptops

#47 2013-02-27 17:30:12

Re: Booting Linux using UEFI can brick Samsung laptops

#48 2013-03-03 11:31:19

Re: Booting Linux using UEFI can brick Samsung laptops

#49 2013-03-03 13:38:22

Re: Booting Linux using UEFI can brick Samsung laptops

#50 2013-03-03 14:12:56

Re: Booting Linux using UEFI can brick Samsung laptops

Board footer