It's a great write-up (follow the next parts if you've only seen the 1st one)
I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
Writing a Bootloader
11–20 of 55 posts
Re: Writing a Bootloader
#12There's even more from Alex: Part 2 [0] covers getting into 32-bit protected mode, and part 3 [1] deals with compiling, linking and running C++ code. There is also a very nice presentation available [2]:
[0] http://3zanders.co.uk/2017/10/16/writing-a-bootloader2/
[1] http://3zanders.co.uk/2017/10/18/writing-a-bootloader3/
[2] http://3zanders.co.uk/2017/10/13/writing-a-bootloader/writin...
Re: Writing a Bootloader
#13It's a great write-up (follow the next parts if you've only seen the 1st one) I wonder how this changes by booting from UEFI (and not using any 'emulation mode')
UEFI itself might be tricky but, actually, nothing stops you from burning those 512 bytes on a flash drive and booting from it on Legacy mode.
Re: Writing a Bootloader
#14> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
[deleted]
Re: Writing a Bootloader
#15> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
Adding to the already existing examples: Back in 1998, the CIH virus https://en.wikipedia.org/wiki/CIH_(computer_virus) bricked quite a few computers by overwriting the BIOS.
Re: Writing a Bootloader
#16> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
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/docum...
Re: Writing a Bootloader
#17> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
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...
Re: Writing a Bootloader
#18> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
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…
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.
Re: Writing a Bootloader
#19> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
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…
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.
Re: Writing a Bootloader
#20> QEMU is great because you don’t have to worry about accidentally destroying your hardware with badly written OS code Is that actually possible?
You can brick laptops with rm -rf /