moonlit Posted February 7, 2009 Share Posted February 7, 2009 This is probably a bit more extreme than most of the posts in here, but I figured I'll throw it out and see what happens... Way back when Commodore was still alive (the first time around, not the back-from-the-dead-Commodore-in-name-only performance gaming PC company), the Amiga OS had a RAD disk, which was a RAM disk that could survive a soft reset. It could store random data or even the OS itself once an OS had been installed to it. I don't know of any current implementation of this so I got to thinking. Basically I imagine this as an area in RAM which isn't touched by the OS during normal use. That is, no running code, no stored data, just straight untouched. The easiest way of protecting a chunk of RAM that I know of without rewriting the OS is to use RAM which isn't/can't be addressed by the OS during normal use. Nowadays the most obvious example of this is a 32bit OS on hardware with more than 4GB RAM. Providing nothing erases the contents of this RAM it should survive as long as power is applied to the RAM (much like the original Amiga implementation). Now I don't think it'd be impossible to add the same functionality to systems now, given that addresses above 4GB are not used by a 32bit OS and are untouched. This makes a perfect scenario to attempt the above scenario. If 64bit code exists beneath the OS (hypervisor, BIOS, EFI, bootloader) then that RAM is still addressable and I believe it could be used as a giant RAD disk as long as the OS has some way to read and write to it. So imagine some form of address translation in that 64bit code, perhaps even a disk emulator of some kind, so the OS either sees the space as a hard disk drive or some other storage device which could be accessed using a driver to talk to the underlying code, whether it be in the BIOS or a hypervisor. If the space was presented as a disk, the OS could be booted from it. Once the OS is installed or imaged to the RAM it would run there believing it was running on a real HDD (again mimicking the RAD disk's ability to support an OS). It would be unaware of the real world situation because it would be unable to "see" the RAM above the 4GB limit, it would only "see" the simulated HDD it's installed on as a real drive according to the hypervisor or BIOS beneath it. To continue the HDD idea, the unaddressed RAM would be able to hold a straight image so would not require specifically written filesystems, it would work in much the same way as a virtual HDD used in an emulator or virtual machine would, a flat image is presented to the guest OS as a real drive. My (lack of) technical knowledge prevents me from exploring this idea any further but I'd be interested in thoughts or opinions on the topic. If anyone believes they could put this down in code form I'd be very interested to see it come to life. (4:17am, 09/02/09): This could also be used to copy a live OS image, for example a liveCD image, to the RAM of a machine using something like OpenBIOS (previously LinuxBIOS). The image could be copied to a machine's RAM at the start of a day from a USB stick or via a network connection by a small piece of code which could be written into OpenBIOS and providing the power remains on, the machine could reboot at each logoff and require no media to boot again. This would result in a completely medialess (and potentially USB-less, if network-driven) machine which could be used as a totally clean public terminal with no external connections or drives accessible. (4:36am, 09/02/09): If the image is downloaded via the network, the OpenBIOS could checksum to ensure that the image is present, correct and untampered. If the image is missing, corrupt or has been tampered with, download a fresh copy before booting. If the checksum is correct, boot as normal. Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.