4 ms·

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 kn

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 14y ago
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 14y ago
  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 14y ago
    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.
- simias 14y ago
  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.
  - keeperofdakeys 14y ago
    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.
    - bd_at_rivenhill 14y ago
      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."
      - entropy_ 14y ago
        With various laptops I've owned over the years, this almost always fixes the problem when the laptop refuses to boot(except when there's actual hardware failure). It's usually pretty straightforward to do too.
- Hoff 14y ago
  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.
- hexonexxon 14y ago
  Or just learn how to do it properly Getting Code Right And Secure, The OpenBSD Way http://www.bsdcan.org/2010/schedule/events/172.en.html http://www.bsdcan.org/2010/schedule/events/172.en.html
xmodem 14y ago
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?
- cdawzrd 14y ago
  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.
- Someone 14y ago
  I expect that you also would like "hardware should be designed to always provide a way to update all of its software" to be true. I don't think you can expect both to be true nowadays. For example, chances are that your battery charging 'hardware' runs some software. That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) This applies elsewhere, too. Historically, we had the 'killer poke' (http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html; variants at http://en.wikipedia.org/wiki/Killer_poke http://en.wikipedia.org/wiki/Killer_poke). Nowadays, it is rumored that buggy baseband firmware for mobile phones can fry the hardware. I do not think it is feasible to prevent all of these in hardware. Because of that, you must accept "if you can update all software through software, you can brick your device through software". So, to get to "provide a way to recover from any failure mode that can result from software", you will need to have some unmodifiable software on the device. You also will need that software to allow updating of some firmware and to be free of bugs. I think that is possible, but not economically feasible. Why would anyone spend even a week on bug-checking that earliest running code on a device that will be sold for only six months? That would be giving up the bestselling 4% of the sales cycle.
  - xmodem 14y ago
lmm 14y ago
"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.
stephengillie 14y ago
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.
- tarabukka 14y ago
  I think finding a kernel exploit in the server's OS that let you run the firmware-bricking code would probably be more viable than installing a new operating system.
cube13 14y ago
It's worth pointing out that Samsung does have a history of issues with "secure" bootloaders. https://plus.google.com/u/0/101093310520661581786/posts/Drq9uJbkGfq https://plus.google.com/u/0/101093310520661581786/posts/Drq9...

keeperofdakeys 14y ago

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 14y ago
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 14y ago
  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.
simias 14y ago
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.
- keeperofdakeys 14y ago
  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.
  - bd_at_rivenhill 14y ago
    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."
    - entropy_ 14y ago
      With various laptops I've owned over the years, this almost always fixes the problem when the laptop refuses to boot(except when there's actual hardware failure). It's usually pretty straightforward to do too.
Hoff 14y ago
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.
hexonexxon 14y ago
Or just learn how to do it properly Getting Code Right And Secure, The OpenBSD Way http://www.bsdcan.org/2010/schedule/events/172.en.html http://www.bsdcan.org/2010/schedule/events/172.en.html

xmodem 14y ago

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?

cdawzrd 14y ago
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.
Someone 14y ago
I expect that you also would like "hardware should be designed to always provide a way to update all of its software" to be true. I don't think you can expect both to be true nowadays. For example, chances are that your battery charging 'hardware' runs some software. That software, if replaced with faulty software, can destroy your batteries and with it, maybe even your motherboard (through fire, acid leaks, and the like) This applies elsewhere, too. Historically, we had the 'killer poke' (http://www.6502.org/users/andre/petindex/poke/index.html http://www.6502.org/users/andre/petindex/poke/index.html; variants at http://en.wikipedia.org/wiki/Killer_poke http://en.wikipedia.org/wiki/Killer_poke). Nowadays, it is rumored that buggy baseband firmware for mobile phones can fry the hardware. I do not think it is feasible to prevent all of these in hardware. Because of that, you must accept "if you can update all software through software, you can brick your device through software". So, to get to "provide a way to recover from any failure mode that can result from software", you will need to have some unmodifiable software on the device. You also will need that software to allow updating of some firmware and to be free of bugs. I think that is possible, but not economically feasible. Why would anyone spend even a week on bug-checking that earliest running code on a device that will be sold for only six months? That would be giving up the bestselling 4% of the sales cycle.
- xmodem 14y ago

lmm 14y ago

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

stephengillie 14y ago

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.

tarabukka 14y ago
I think finding a kernel exploit in the server's OS that let you run the firmware-bricking code would probably be more viable than installing a new operating system.

cube13 14y ago

It's worth pointing out that Samsung does have a history of issues with "secure" bootloaders. https://plus.google.com/u/0/101093310520661581786/posts/Drq9uJbkGfq https://plus.google.com/u/0/101093310520661581786/posts/Drq9...