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

21–30 of 55 posts

Re: Booting Linux using UEFI can brick Samsung laptops

#21

Post by simias »

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.

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.

Re: Booting Linux using UEFI can brick Samsung laptops

#22

Post by keeperofdakeys »

guilloche wrote: post #14

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.

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.

Re: Booting Linux using UEFI can brick Samsung laptops

#24

Post by keeperofdakeys »

simias wrote: post #21
keeperofdakeys wrote: post #17

Earlier quoted context omitted.

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.

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, and doing it in software is much cheaper.

There will usually be some kind of firmware reset in the hardware, but it might involve processes that only the manufacturer can do.

I would say C's memory model can contribute towards this because if you have a buffer overflow, or change the wrong bits of memory, you might accidentally change the code, or execute data. Executing data is why buffer overflows are so serious, and allow malicious code to essentially do anything.

Re: Booting Linux using UEFI can brick Samsung laptops

#25

Post by keeperofdakeys »

UnoriginalGuy wrote: post #20
keeperofdakeys wrote: post #17

Earlier quoted context omitted.

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.

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…

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.

Re: Booting Linux using UEFI can brick Samsung laptops

#27

Post by 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-... # but nothing else in there looks to be any closer either

Re: Booting Linux using UEFI can brick Samsung laptops

#30

Post by cdawzrd »

xmodem wrote: post #19
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…

Yes - hardware should be designed to always provide a way to recover from any failure mode that can result from software that's running on that hardware. Even bad firmware updates should be recoverable - what happens if you lose power mid-update?

Bad firmware updates are (almost always) recoverable, just not always (easily) by the end user. What happens when you lose power is that you need to use the hardware-level debugging/testing functionality of whatever programmable device is in question--JTAG, for example--to load a running firmware image and then reprogram the half-programmed flash storage.
Post reply on HN