1

Can a real mode program which can write to arbitrary memory areas, damage hardware? Not included in this scenario are interrupt calls or other things that can be done in real mode - just pure writing to memory.

This page shows a memory map of x86 systems, and I see stuff like BIOS data area; so I fear that writing to this area might do persistent changes to the BIOS, or at least change the BIOS settings to unexpected values. The are probably more things that can be destroyed.

I often read that hardware access in real mode can destroy hardware; but they do not explain the circumstances which have to be made.

Since I am only asking about writing access without invoking interrupts, my main question is, if changes to the memory can do persistent changes; and if yes, which and why?

Daniel Marschall
  • 3,739
  • 2
  • 28
  • 67
  • I think you are safe trying to write to ROM. (Look up what it stands for.) – Scott Hunter Oct 30 '15 at 23:07
  • I do know what ROM means. But you can flash a ROM. And you can change BIOS settings which may be inconsistent, and therefore crash the next boot. There are probably more things that can get wrong – Daniel Marschall Oct 30 '15 at 23:12
  • If the "ROM area" is actually made of ROM chips, you can't change it. You can't flash a ROM chip. – Scott Hunter Oct 30 '15 at 23:16
  • I am not sure what kind of chips are used to store the BIOS, and how flashing works (I assume that at least an interrupt is invoked, though) . However , during my research I often heard that real mode programs can damage hardware, but I didn't get verbose information under which circumstances this can happen. My main question is, if writing to arbitrary memory can make a persistent change to the system. – Daniel Marschall Oct 30 '15 at 23:21
  • Yes, but not by writing to an actual ROM. – Scott Hunter Oct 30 '15 at 23:23
  • 1
    ... Whoever voted me down, should show me the lack of research I did. For example http://stackoverflow.com/questions/6813636/risk-of-damaging-your-computer-by-altering-memory-in-c, a 6 times upvoted question asks the same, and the answer in regards to real mode is "any access can damage anything". This is not enough for me! :-( I would like to understand what change to which memory area will cause which damage, and why. – Daniel Marschall Oct 30 '15 at 23:31
  • If you write to the video display memory using an old CRT monitor and then leave the display on with the same text for a long period of time it will eventually cause screen burn in, which is hardware damage. – Michael Petch Oct 31 '15 at 00:14
  • 1
    I do not know of any memory location in the Bios Data Area or the Extended BDA that if written to would cause physical damage to the PC. However if you write to those areas your PC may not function as expected and may require a reboot to resolve. If you interact directly with hardware using IO ports then you can do some nasty things that may make your PC not work afterwards on some older/buggy BIOSes. Many BIOSes can be reflashed with new code, and if that code is bad then your PC may not boot in the future.Many systems now come with a backup copy of a working BIOS just in case. – Michael Petch Oct 31 '15 at 00:29
  • agreed, you can probably trash the bios(es) but would need access to I/O to have the best shot at doing real damage. Never say never at this point, everything including the laptop batteries have processors in them that can be hacked and, you could for example allow a battery to overcharge and catch fire or worse. can you do it in real mode? not sure. COTS equipment is not meant to be fault tolerant or hacker proof, just cheap and available, so yes in general software can do hardware damage, but when you start to put limits on the software access you limit the damage. – old_timer Oct 31 '15 at 01:44
  • slowing or turning the fans off if you can and can get away without some other hardware stopping you is another good one for doing damage...it happens enough on its own to fry things when the fans wear out... – old_timer Oct 31 '15 at 01:46
  • If the program was in protected mode, you get access to the memory-mapped IO of the PCIe bus. Imagine the fun one could have in there when in a bad mood! Turning-up the gpu speed and cranking down the fan-speed on the video card wont end-up well. – enhzflep Oct 31 '15 at 04:11

1 Answers1

7

Assuming modern 80x86 hardware; things that won't cause persistent changes and/or damage include:

  • changing anything that is reset when the computer is reset; including all contents of RAM, caches, the CPU's micro-code, etc.

  • writing to the area that legacy ROMs are copied to RAM (the area from 0x000C0000 to 0x000FFFFF). Note that this is actually RAM, but set to "ignore writes" in the memory controller after POST.

  • writing to the area that actually contains the firmware (the "n MiB" area that ends at 0xFFFFFFFF).

Things that will cause "temporarily persistent changes" (that can be fixed) include:

  • writing trash to CMOS registers; which is no worse than getting a flat CMOS battery on older systems and is likely to result in a "CMOS settings not valid" error (due to a checksum mismatch) next time you boot; and can be fixed via. firmware's configuration utility at boot.

  • trashing data on storage devices (hard disks, USB flash, etc). Can be fixed by restoring from backup and/or reinstalling software.

Things that might cause unfixable persistent changes include:

  • writing to firmware's flash. This typically (but not always) involves an intricate sequence just to unlock it, followed by "guessing" a correct encryption key and/or digital signature. Note that this is very difficult if you're deliberately trying to do it, and almost impossible by accident.

  • writing to a device's flash ROM (if it has any), which might include hard disk's internal controller, printers, etc. This typically (but not always) involves protections to prevent it. Note that this also almost impossible to do by accident.

Things that might cause actual physical damage include:

  • repeatedly smashing floppy drive heads against their stop (e.g. by seeking to "cylinder 99" that doesn't exist for maybe several hours) in an attempt to reduce the life expectancy of the floppy drive.

  • attempting to use high resolution video modes on some extremely old "VGA only CRT" monitors (which can't handle the higher frequencies and blow up). Note that blowing these ancient monitors up is about the only thing they're good for.

  • attempting to set an unsupported video mode (e.g. with higher than sane refresh rate) on some cheap and nasty (and rare) laptops; where its possible to boil the liquid in the liquid crystal display.

Note that most of the things above either require the use of protected mode or long mode (and can't work in real mode), or involve IO ports in some way (not just memory writes).

Brendan
  • 35,656
  • 2
  • 39
  • 66
  • Thank you for your detailled and helpful answer. The parts with "almost impossible to do by accident" sound very good to me, so I should probably not be worried if a memory access in real mode goes from wrong due to a bug. – Daniel Marschall Oct 31 '15 at 21:44
  • @DanielMarschall: These days, unless you need your code to interact with specific hardware to test it, it should be a lot easier to do your compile/debug/edit cycle with an emulator like bochs, which has a debugger built in. It should be able to single-step anything. But yes, booting buggy code on real hardware is very unlikely to cause problems a reboot can't solve, and extremely unlikely to cause physical damage. – Peter Cordes Oct 31 '15 at 22:36