Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Booting Linux using UEFI can brick Samsung laptops

h-online.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Booting Linux using UEFI can brick Samsung laptops

#31

Post by bd_at_rivenhill »

keeperofdakeys wrote: post #24
simias wrote: post #21

Earlier quoted context omitted.

If you can brick the hardware with a bogus driver it looks more to me like a hardware bug rather than a software one. Why exactly do you blame C's memory model for this issue? The article is not overly specific about the exact specifics of the problem. Do you have a more technical source? I'd be curious to learn how exactly this driver can completely brick the mobo.

I don't have any technical sources for this bug, but I'm quite certain it would be a bug in either the UEFI firmware or the kernel driver. Firmware can be quite complicated pieces of software, and if you accidentally change the wrong memory values, you might trigger a firmware update or change configurations of the hardware present in the firmware. All this stuff can be changed because it needs to be configurable, an…

Seems like the best solution is that there should always be a way to reset the firmware to a hard-coded factory default which represents the state that existed when the machine came off the assembly line. In this way, a bad firmware update can always be rolled back.

EDIT: looks like somebody reporting the bug did this the old-fashioned way: "Just to add, on UEFI machines that got bricked like this I removed the battery and disconnected the CMOS NVRAM battery and this restored the machine to the factory default and fixed the issue for me."

Re: Booting Linux using UEFI can brick Samsung laptops

#32

Post by Hoff »

keeperofdakeys wrote: post #17
UnoriginalGuy wrote: post #12

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

The word is bugs. It's very hard, and almost impossible to fix all bugs. Code with no bugs is really code with no known bugs. Especially when dealing with C and assembly, different parts of the code can effect other parts in ways a programmer may not anticipate. You really need to get a 'safer' language to prevent certain types of bugs, especially with the "data and code share the same segments" model of C.

Yes, bugs happen.

So what can be done?

There are systems with firmware that can automatically detect failed updates or corrupted firmware, or where a failsafe firmware loader can be triggered by a jumper or related request, and that can then perform a reset and (re)load of replacement firmware.

Without requiring a test harness or JTAG access or other equipment.

In various of these cases, there are two copies of the firmware, meaning the old firmware can be immediately accessed, or — pending successful completion — a second copy of working firmware can be generated.

In one case, a system had its firmware mostly in ROM, and had NVRAM that could hot-patch routines via an NVRAM-based vector table, and with space for replacement routines in the NVRAM. This meant that the box would always boot, and bad vectors could be detected by checksum, and firmware bugs could still be patched up to the limit of the available NVRAM.

Put another way, we know how to avoid this mess. It just costs some time and effort and money, and that can get this capability cut.

This stuff is not rocket science.

Re: Booting Linux using UEFI can brick Samsung laptops

#33

Post by tinco »

RexRollman wrote: post #11
ygra wrote: post #4

Earlier quoted context omitted.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

The PC was only a success for the market as a whole. The setters of the standards did not profit from it at all and even went (close to) bankruptcy because of it.

Contrast this closed hw architectures like Nintendo and Apple produce. No consumer freedom but incredible profit margins.

Note that modern macs are in fact PC's with just minor modifications so they profit from the PC economies of scale while still locking their customers into their hardware platform.

Re: Booting Linux using UEFI can brick Samsung laptops

#34

Post by lmm »

UnoriginalGuy wrote: post #12

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

"Should"? In some academic sense, of course everything should be engineered perfectly. But in the real world there are tradeoffs, and people pay more for flexibility and functionality than for safety. I don't see that changing in the near term.

Re: Booting Linux using UEFI can brick Samsung laptops

#35

Post by davidp »

RexRollman wrote: post #11
ygra wrote: post #4

Earlier quoted context omitted.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

What if lockdown worked in such a way that you could lock it down to only run your Linux kernels? E.g. load up your own certificate in the TPM and use that for signing when you build.

In that case it would be a security feature -- another line of defense against bootloader malware and/or adversaries in physical possession of your machine.

(I don't know how technically feasible that is; I know Canonical and others are looking at having their own cert so at least their unmodified kernels can run, but I don't know the mechanism for how that interacts with already-released UEFI machines.)

The point is that technologies like this are a double-edged sword, not evil in themselves. A similar argument is made by Linus himself for sticking with GPL v2 instead of moving to GPL v3, which outlaws certain DRM-related uses; he's more interested in providing a functioning mechanism, and leaving the policy-setting to others.

Re: Booting Linux using UEFI can brick Samsung laptops

#36

Post by stephengillie »

UnoriginalGuy wrote: post #12

So random academic question - Should it be literally possible for an OS to "brick" hardware even if the OS was intentionally designed to do just that? Now I know in this particular case Samsung wrote both the driver and the firmware, so it is easy to point blame here. But more broadly, should hardware be built/designed so it has a "fail safe" mode where it just won't allow its self to be damaged by OS/software instru…

Are you describing a Denial of Service attack? One where the attacker would get the desktop or server to try to install and run Arch Linux, then let it brick itself? If a critical Windows server or workstation was hit, this could cause a project to grind to a halt.

Re: Booting Linux using UEFI can brick Samsung laptops

#37

Post by wmf »

nextparadigms wrote: post #23

Why can't they just use Google's method for the Chromebooks? I think it allows to easily install any other OS as soon as you physically disable the bootloader with a switch on your laptop.

Because they're not as smart as Google. Most hardware vendors budget as little as possible for firmware, and the result is predictable.

Re: Booting Linux using UEFI can brick Samsung laptops

#38

Post by rbanffy »

RexRollman wrote: post #11
ygra wrote: post #4

Earlier quoted context omitted.

I guess Surface Pro will be locked down via Secure Boot and won't ever boot Linux unless jailbroken. Whether that's inherently better is probably another question.

It's sad that everybody wants to lock everything down. It's like no one learned anything from the success of the PC.

The PC was a success mostly for Microsoft. With the commoditization of hardware around a single software option, PC makers were squeezed and their margins are exceedingly thin. It's the "thin slice of a larger pie" metaphor. It's just that Microsoft has the whole OS pie, while every hardware maker has a vanishingly thin slice of it.

Re: Booting Linux using UEFI can brick Samsung laptops

#39

Post by nathell »

daeken wrote: post #5
RexRollman wrote: post #2

Say what you will about the old BIOS systems but at least it worked and everyone understood it. EFI/uEFI seems to be a big clusterfuck.

I am completely and utterly baffled by this statement. Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. I've dealt with kernel dev for BIOS systems, CSM development for UEFI, etc etc. I'll stick with UEFI, even if it does still have some growing pains.

> Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly.

Isn't it the case that once the kernel is fully booted, up and running, it bypasses BIOS entirely and talks directly to the hardware? Have all those bugs you mention been related to the booting process itself (constituting a relatively tiny part of the kernel)?

Re: Booting Linux using UEFI can brick Samsung laptops

#40

Post by gizmo686 »

nathell wrote: post #39
daeken wrote: post #5

Earlier quoted context omitted.

I am completely and utterly baffled by this statement. Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. I've dealt with kernel dev for BIOS systems, CSM development for UEFI, etc etc. I'll stick with UEFI, even if it does still have some growing pains.

> Do you realize how many man-years have been spent working around BIOS bugs over the years? Get any kernel developer a drink, then just say the word 'BIOS'; your opinion of UEFI will change pretty rapidly. Isn't it the case that once the kernel is fully booted, up and running, it bypasses BIOS entirely and talks directly to the hardware? Have all those bugs you mention been related to the booting process itself (con…

I do not know to what extent the OS bypasses the BIOS, but it is not completly. If you look in the linux kernel config, you will see an option to control how much RAM is reserved for BIOS. Also, on (many?) Dells, Fn+Shift+15324 followed by Fn+r brings up BIOS thermal controls [1]. I have verified this on an Inspiron 1420, in Windows 7 and Ubuntu 12.10 (kernel 3.5.0-21-generic).

[1]http://ubuntuforums.org/showthread.php?t=1684657

Post reply on HN