
Booting Linux using UEFI can brick Samsung laptops - fuzzix
http://www.h-online.com/open/news/item/Booting-Linux-using-UEFI-can-brick-Samsung-laptops-1793958.html
======
UnoriginalGuy
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
instruction?

PS - Let's just assume BIOS/uEFI firmware updates are off the table for this
discussion. Since many modern uEFIs allow you to disable user updates
entirely.

~~~
keeperofdakeys
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.

~~~
UnoriginalGuy
It isn't /just/ bugs. It is also the way we think about the relationship
between the underlying hardware and the kernel/OS.

There is an inherent level of "trust" there. Which makes sense. But the
question is: should that "trust" extend to permanent damage to the
hardware/firmware?

For example, a lot of GPUs allow the OS to control fan speed. You can
literally set the fan speed so low the GPU will over-heat and damage its self.
That isn't a "bug" that is a "feature."

Again, we come back the expectations/relationship.

~~~
keeperofdakeys
It's always said "hardware is expensive, software is cheap; so do as much as
you can in software". When you also remember that we give an OS full control
of all hardware, it's the natural conclusion that things like this can happen.
Although, this is changing, subtly. Now you have harddrives and SSDs that run
their _own_ software that can't be controlled by the OS. The firmware may even
lie to the OS, for example harddrives might tell the OS "I've written this
data", when it might actually be caching it for more efficient writing.
Unfortunately computes are nearly infinitely complex these days, with so many
layers developed by many people.

------
Breakthrough
I was about to pick one of these laptops up late last year until I happened to
stumble across that very bug report myself:
[https://bugs.launchpad.net/ubuntu-
cdimage/+bug/1040557?comme...](https://bugs.launchpad.net/ubuntu-
cdimage/+bug/1040557?comments=all) Everyone seems to have it working fine with
UEFI disabled, and several people have noted the vendor or Samsung has
provided a replacement in the cases where it was bricked.

At least in their darkest hours, Linux users can still put on a smile:

" _[...] they changed the motherboard and it's working again now. I won't try
to install Ubuntu again though. The whole process took about 2 weeks._ "

------
speeder
I wish UEFI was designed more with the user in mind and less politics and
corporate decisions.

To start, it should not possible to brick a hardware in any way...

Interestingly, the UEFI looks to me sufficiently complex to control the device
graphics and input before the OS boots, I wonder if that can be used to abuse
the system and do again some "on the metal" coding for high performance stuff
(ie: games... and scientific things).

I think maybe that cannot be done because probably no UEFI comes with drivers
for video hardware acceleration.

------
RexRollman
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.

~~~
daeken
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.

~~~
nathell
> 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)?

~~~
gizmo686
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>

------
josteink
The biggest problem with UEFI was that someone decided to mess it up and
complicate it by adding DRM and signing-requirements.

It's the result of computing following designs mandated by the MPAA/RIAA. Who
on earth thought that could turn out OK?

~~~
dmm
UEFI has _NOTHING_ to do with DRM.

------
guilloche
Bios is outdated, but UEFI is even worse and became such a mess. It did not
fix BIOS's issues and is unnecessary complicated. The efforts are regretfully
wasted on UI.

~~~
keeperofdakeys
Sorry, but the BIOS had many issues, and UEFI provided a solution to them,
even if it wasn't an inherently good system.

1.The BIOS isn't portable, you can compile UEFI for any platform by porting a
small base module. Everything uses this module, so the compiler will take care
of the rest.

2\. BIOS was a heap of 16bit assembly code, with a small memory space. It was
quite hard to add any kind of complex functionality.

3\. You couldn't use a boot volume greater than 2TB due to MBR. A new one
wasn't added because of number 2.

4\. UEFI is more like a micro kernel then a generic BIOS, and provides the
functionality for vendors to write 'better' interfaces. Here the interfaces
aren't actually provided in the official UEFI sample implementation, and most
can be arguably called worse then an average BIOS interface. However, you have
to acknowledge the capability is there.

5\. It added a framework for kernel verification (unlike what some people
think, it only verifies the UEFI firmware and the kernel/boot loader it loads
directly). The direction that Microsoft is taking it is quite unfortunate, but
it's actually a good feature.

6\. It has a limited capability as a boot loader, allowing multiple operating
systems to be started directly.

These are all features that aren't present in the BIOS, that UEFI has fixed.
Unfortunately the current implementation has many bugs, and many features are
arguably implemented badly. However is was created to fix real problems, and
has been undeniably successful at that. At a linux conference there was a talk
about all this, from someone quite involved with the UEFI creation process. If
you are interested, the recording will probably be released in a few weeks.
There is also a talk from the previous year by Matthew Garrett (the guy who
does UEFI stuff in Linux), talking about all the bugs present in UEFI, which
is an entertaining watch, <https://www.youtube.com/watch?v=V2aq5M3Q76U>.

~~~
RexRollman
It sounds like UEFI is over-engineered. All I want is for something to
initialize the hardware and hand over for booting.

~~~
guilloche
"over-engineered" is the right word for UEFI.

------
protomyth
I do so miss OpenFirmware (forth and all).

------
noonespecial
Looks like a roadmap for some truly nasty malware. This should not be possible
in any circumstance. It's like having a history eraser button on your
spaceship.

------
albertzeyer
Just disabling the driver doesn't seem like the ultimate solution... Have they
even identified the problem itself? Why aren't they just fixing it? Is it on
the hardware site or in the driver software? They should fix that.

------
telent
As stories go, this one would be a lot better if it actually linked to some
technical information about the bug. Does anyone have a reference for what the
samsung_laptop driver's doing that is so bad? The kernel bugzilla link
(#47121) that someone has speculated is related is a boot panic, not a
complete bricking, so while it _may_ be the same thing ...

[https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-...](https://bugzilla.kernel.org/buglist.cgi?quicksearch=samsung-
laptop) # but nothing else in there looks to be any closer either

------
mixmastamyk
U/EFI is an interesting subject. Yes, of course better than the primitive bios
it replaced. Interesting in that you can can play with a new OS.

But, Intel went out and invented another operating system? Why, when embedded
Linux (&coreboot) already existed? with a full stack of software? Would be
nice to have a web browser available from the firmware for downloading
drivers, etc. I ran Linux on an Itanium at work circa 2003 so it was
definitely doable.

Is the answer that MS wouldn't allow it? Or is there another reason?

------
nogoodnik
In a few weeks, "Don't buy Samsung laptops" is what I will remember from this.

------
nextparadigms
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.

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

------
spyder
Just fixing the driver doesn't seems a safe solution, because then malwares
still can do the same to brick the hardware, isn't? Sure nowadays most
malwares don't want to brick your hardware because ads are more profitable but
it can still happen. It's understandable that new technologies have more
serious bugs than decades old ones and hopefully it will be fixed in UEFI
soon, but this shows why you have too be careful with new technologies if you
are an early adpoter.

