47 ms·

> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?

d33 9y ago
I'd say yes. Especially if you mess with ACPI and, say, turn off the fans...
- colejohnson66 9y ago
  Modern processors just thermal throttle to the extreme if the heat can’t be dissipated, no?
  - perbu 9y ago
    They will shut down the whole computer.
  - exikyut 9y ago
    Experience with an incorrectly heatsunk laptop GPU has demonstrated to me that the BIOS will yank power to the system if it hits 100°C. Yeah. Well, in all honesty I'm not sure if it was Linux, the BIOS, or some low-level thermal monitoring circuitry, but yeah, I one minute I was messing around with WebGL and the next minute I got confused about whether I'd forgotten the power cable. (Then I realized I hadn't heard any beeping (this was a ThinkPad and I didn't have the beeper muted) and realized it had overheated.)
perbu 9y ago
The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where you could position the head to an impossible position causing the servo to burn. Haven't heard of anything like what he is describing the last 20 years. Perhaps you can overheat some stuff - but most likley it'll shut down before anything bad happends. There are however some worrying notes on OSDEV about causing potential damage when probing for memory, perhaps the author read this and got worries. It isn't detailed or likely, imho.
- colejohnson66 9y ago
  On computers where `efivars' is mounted read-write, you can possibly brick your UEFI by deleting the contents of that “file system” https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
- deleted 9y ago
  [deleted]
- ihale 9y ago
  I've always been told that there is risk of irreversible hardware damage. I haven't any idea where this claim comes from, and I've never been offered an explanation. It's one of the things that has always made me wonder, and why I've never tested any of my own code on real hardware. I'd be curious to see this claim expanded, or debased.
- amiga-workbench 9y ago
  On the Commodore PET you could write a short BASIC program to rapidly change the direction of the tape drive motor, it would fry the transformer that ran it.
  - amyjess 9y ago
    I had a coworker who used to be a C64 enthusiast. One day, a very long time ago, he discovered a C64 program on Usenet called "drive music". He downloaded it and ran it... and his floppy drive started playing music. After playing with it for a while, he heard that using it too much could throw your drive heads out of alignment, so he got rid of it.
    - jerrysievert 9y ago
      For me, alignment problems on the 1541 were fairly common (there was a lot of head thrashing when trying to read "protected" disks), which ended up with the 1541 cover being easily removable for me, and always a screwdriver nearby to recalibrate.
- 9y ago
pjmlp 9y ago
Yep. Back in the early days of GNU/Linux, getting X to run could kill your monitor. Another example, many hard drive controllers used to blindly move their heads to whatever position they were told, even if it was an incorrect position. In the old days you also had to use something like PC Tools to park the heads before moving the computer.
ianopolous 9y ago
As recently as 4 years ago there were Samsung laptops that could be bricked by installing Linux. Apparently there was a special physical memory address that you weren't supposed to poke and which Linux did, which resulted in bricking the laptop. https://arstechnica.com/information-technology/2013/02/booting-linux-instead-of-windows-8-bricks-some-samsung-laptops/ https://arstechnica.com/information-technology/2013/02/booti...
- mjg59 9y ago
  Not quite right. The documented interface that was used for firmware control on BIOS systems generated errors if you poked it on UEFI systems, and the kernel logged those errors into UEFI variables. If the UEFI variable storage filled up, the machine stopped booting. It was possible to trigger the failure by filling the variable store, even under Windows. The workaround was to reserve some variable storage space at all times, but this was made difficult due to the way some UEFI implementations do garbage collection - deleting variables wouldn't free the space. The workaround is to try to create a veritable that's larger than the reported free space in order to trigger garbage collection, but not all implementations will do garbage collection at runtime. So the kernel will check how much free space there is during early boot and try to create an oversized variable in order to trigger gc before it transitions to runtime mode. Last time I checked, Windows did nothing to stop you killing your system. Computers are bad. (source: I debugged this and wrote most of the remediation code)
  - aidos 9y ago
    I love this comment, in part because it's totally outside my area of knowledge but I can still picture the battles and dead ends you must have worked through to make it stable. Did you kill a lot of hardware figuring it out? What was the purpose of poking that caused the underlying issue?
    - mjg59 9y ago
      I only killed one laptop in the end, the rest of the testing was done with VMs and a system that had a hardware EFI variable reset button. The issue that was triggering it on Samsungs was the driver that supported backlight control - it worked by writing a value to an address which triggered some system management mode code in the firmware, but that code only worked properly in BIOS mode. In EFI mode it generated machine check exceptions, which in turn caused the kernel to dump the backtrace to EFI variables.
deleted 9y ago
[deleted]
dividuum 9y ago
Adding to the already existing examples: Back in 1998, the CIH virus https://en.wikipedia.org/wiki/CIH_(computer_virus) https://en.wikipedia.org/wiki/CIH_(computer_virus) bricked quite a few computers by overwriting the BIOS.
shakna 9y ago
Yes. Not as easily as twenty years ago, but still fairly easily. In fact, even well-written code can cause hardware-bugs to burn out your hardware. Modern OS's have a ton of hacks to work around limitations of certain hardware. Example A: Intel's Atom C2000 family. [0] There's quite a few things there, SATA voltages being too high etc., but if we're looking for ultimate destruction then we can't go passed AVR54 from the errata. > The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning. If you lose the LPC clock... The system won't boot anymore. The whole story isn't in the link, but apparently the cause for this, is that the clock can suddenly stop functioning if you check it "too often", usually failing after 18 months of use. Cisco has the same problem with some of their routers, from the same hardware. It's a hardware bug, but with a quick BIOS fix, Cisco and Intel have worked around it, and their devices keep working without a recall... But your own code hasn't, and will eventually brick your device. Oh, and notice the date on Intel's link. April, 2017. [0] https://www-ssl.intel.com/content/dam/www/public/us/en/documents/specification-updates/atom-c2000-family-spec-update.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum...
userbinator 9y ago
The possibility is small, but with voltages and frequencies under software control, yes. AFAIK even ordinary "non-overclocker" hardware has this capability, despite not being exposed in the BIOS settings, for power management purposes. This is especially problematic with certain laptops --- I remember hearing about some that would overheat when booted into BIOS or even an alternative OS for an extended period of time, since they depended entirely on a driver to turn on and control the CPU fan...
superflyguy 9y ago
You can brick laptops with rm -rf / https://m.slashdot.org/story/306621 https://m.slashdot.org/story/306621
yipopov 9y ago
Apparently hackers can turn your home computer into a bomb ...& blow your family to smithereens!
coworkerblues 9y ago
Yes in the 80s PC monitors had CGA and MONOCHROME mode, and if you switched fast between them in DOS (you could do mode mono, and mode co80 in a loop) and it fried my GPU :)

d33 9y ago

I'd say yes. Especially if you mess with ACPI and, say, turn off the fans...

colejohnson66 9y ago
Modern processors just thermal throttle to the extreme if the heat can’t be dissipated, no?
- perbu 9y ago
  They will shut down the whole computer.
- exikyut 9y ago
  Experience with an incorrectly heatsunk laptop GPU has demonstrated to me that the BIOS will yank power to the system if it hits 100°C. Yeah. Well, in all honesty I'm not sure if it was Linux, the BIOS, or some low-level thermal monitoring circuitry, but yeah, I one minute I was messing around with WebGL and the next minute I got confused about whether I'd forgotten the power cable. (Then I realized I hadn't heard any beeping (this was a ThinkPad and I didn't have the beeper muted) and realized it had overheated.)

perbu 9y ago

The only times I've heard of destroying hardware with software have been: 1) stopping the ray in a CRT monitor through special purpose registers and using it to burn through the phosphorous. 2) Early floppy drives where you could position the head to an impossible position causing the servo to burn. Haven't heard of anything like what he is describing the last 20 years. Perhaps you can overheat some stuff - but most likley it'll shut down before anything bad happends. There are however some worrying notes on OSDEV about causing potential damage when probing for memory, perhaps the author read this and got worries. It isn't detailed or likely, imho.

colejohnson66 9y ago
On computers where `efivars' is mounted read-write, you can possibly brick your UEFI by deleting the contents of that “file system” https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402
deleted 9y ago
[deleted]
ihale 9y ago
I've always been told that there is risk of irreversible hardware damage. I haven't any idea where this claim comes from, and I've never been offered an explanation. It's one of the things that has always made me wonder, and why I've never tested any of my own code on real hardware. I'd be curious to see this claim expanded, or debased.
amiga-workbench 9y ago
On the Commodore PET you could write a short BASIC program to rapidly change the direction of the tape drive motor, it would fry the transformer that ran it.
- amyjess 9y ago
  I had a coworker who used to be a C64 enthusiast. One day, a very long time ago, he discovered a C64 program on Usenet called "drive music". He downloaded it and ran it... and his floppy drive started playing music. After playing with it for a while, he heard that using it too much could throw your drive heads out of alignment, so he got rid of it.
  - jerrysievert 9y ago
    For me, alignment problems on the 1541 were fairly common (there was a lot of head thrashing when trying to read "protected" disks), which ended up with the 1541 cover being easily removable for me, and always a screwdriver nearby to recalibrate.
9y ago

pjmlp 9y ago

Yep. Back in the early days of GNU/Linux, getting X to run could kill your monitor. Another example, many hard drive controllers used to blindly move their heads to whatever position they were told, even if it was an incorrect position. In the old days you also had to use something like PC Tools to park the heads before moving the computer.

ianopolous 9y ago

As recently as 4 years ago there were Samsung laptops that could be bricked by installing Linux. Apparently there was a special physical memory address that you weren't supposed to poke and which Linux did, which resulted in bricking the laptop. https://arstechnica.com/information-technology/2013/02/booting-linux-instead-of-windows-8-bricks-some-samsung-laptops/ https://arstechnica.com/information-technology/2013/02/booti...

mjg59 9y ago
Not quite right. The documented interface that was used for firmware control on BIOS systems generated errors if you poked it on UEFI systems, and the kernel logged those errors into UEFI variables. If the UEFI variable storage filled up, the machine stopped booting. It was possible to trigger the failure by filling the variable store, even under Windows. The workaround was to reserve some variable storage space at all times, but this was made difficult due to the way some UEFI implementations do garbage collection - deleting variables wouldn't free the space. The workaround is to try to create a veritable that's larger than the reported free space in order to trigger garbage collection, but not all implementations will do garbage collection at runtime. So the kernel will check how much free space there is during early boot and try to create an oversized variable in order to trigger gc before it transitions to runtime mode. Last time I checked, Windows did nothing to stop you killing your system. Computers are bad. (source: I debugged this and wrote most of the remediation code)
- aidos 9y ago
  I love this comment, in part because it's totally outside my area of knowledge but I can still picture the battles and dead ends you must have worked through to make it stable. Did you kill a lot of hardware figuring it out? What was the purpose of poking that caused the underlying issue?
  - mjg59 9y ago
    I only killed one laptop in the end, the rest of the testing was done with VMs and a system that had a hardware EFI variable reset button. The issue that was triggering it on Samsungs was the driver that supported backlight control - it worked by writing a value to an address which triggered some system management mode code in the firmware, but that code only worked properly in BIOS mode. In EFI mode it generated machine check exceptions, which in turn caused the kernel to dump the backtrace to EFI variables.

deleted 9y ago

[deleted]

dividuum 9y ago

Adding to the already existing examples: Back in 1998, the CIH virus https://en.wikipedia.org/wiki/CIH_(computer_virus) https://en.wikipedia.org/wiki/CIH_(computer_virus) bricked quite a few computers by overwriting the BIOS.

shakna 9y ago

Yes. Not as easily as twenty years ago, but still fairly easily. In fact, even well-written code can cause hardware-bugs to burn out your hardware. Modern OS's have a ton of hacks to work around limitations of certain hardware. Example A: Intel's Atom C2000 family. [0] There's quite a few things there, SATA voltages being too high etc., but if we're looking for ultimate destruction then we can't go passed AVR54 from the errata. > The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning. If you lose the LPC clock... The system won't boot anymore. The whole story isn't in the link, but apparently the cause for this, is that the clock can suddenly stop functioning if you check it "too often", usually failing after 18 months of use. Cisco has the same problem with some of their routers, from the same hardware. It's a hardware bug, but with a quick BIOS fix, Cisco and Intel have worked around it, and their devices keep working without a recall... But your own code hasn't, and will eventually brick your device. Oh, and notice the date on Intel's link. April, 2017. [0] https://www-ssl.intel.com/content/dam/www/public/us/en/documents/specification-updates/atom-c2000-family-spec-update.pdf https://www-ssl.intel.com/content/dam/www/public/us/en/docum...

userbinator 9y ago

The possibility is small, but with voltages and frequencies under software control, yes. AFAIK even ordinary "non-overclocker" hardware has this capability, despite not being exposed in the BIOS settings, for power management purposes. This is especially problematic with certain laptops --- I remember hearing about some that would overheat when booted into BIOS or even an alternative OS for an extended period of time, since they depended entirely on a driver to turn on and control the CPU fan...

superflyguy 9y ago

You can brick laptops with rm -rf / https://m.slashdot.org/story/306621 https://m.slashdot.org/story/306621

yipopov 9y ago

Apparently hackers can turn your home computer into a bomb ...& blow your family to smithereens!

coworkerblues 9y ago

Yes in the 80s PC monitors had CGA and MONOCHROME mode, and if you switched fast between them in DOS (you could do mode mono, and mode co80 in a loop) and it fried my GPU :)