5 ms·

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

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.
    - donrhummy 14y ago
      It appears he didn't do that with a Samsung laptop but other machines in the past and someone replied saying it didn't fix it for them: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/24 https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comme...
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

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.
  - donrhummy 14y ago
    It appears he didn't do that with a Samsung laptop but other machines in the past and someone replied saying it didn't fix it for them: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/24 https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comme...

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