4 ms·

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

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.
    - exikyut 9y ago
      > a system that had a hardware EFI variable reset button Ooh, that sounds useful for hardware hackers. What was this?

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.
  - exikyut 9y ago
    > a system that had a hardware EFI variable reset button Ooh, that sounds useful for hardware hackers. What was this?