Why is HORM restricted to EWF-RAM??

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I was wondering if there was a good reason why HORM is limited to EWF-RAM.
The explanations I have seen so far are very shaky at best.

Background
Our product we are developing is going to have 1 GB of RAM in it. Due to
the nature of our product, we would like to use the majority of this RAM to
run our software. We are going to have 2 partitions, 1 HORM/EWF protected
partition for OS and Apps and 1 non-protected partition for user data.

What I have read so far leads me to believe that the reason that HORM must
be used with the RAM overlay is because it needs to keep all the system
information from getting out of sync, but mostly with the disk write cache
which could potentially corrupt your partitions.

This explanation sounds reasonable except you can run HORM/EWF protected and
unprotected partitions together. Shouldn't this cause the same issues that
using EWF-DISK will cause, out-of-sync partition states?

The reason why this is a concern is our product has the potential to write a
lot of data as the product is used, which could eat up RAM very quickly (We
are limited on the board we are using to 2 GB.) We would like to use a hard
drive partition as we can set the size to 5-7GB without much concern.

As the main reason for using HORM is that you want a to keep the device in
the same state every time you boot up the device, why should it matter what
is in the overlay? You should expect to loss it anyways.

Does anyone know if this current HORM limitation something that will be
addressed later on to make it more appealing as an option to protect devices
that need the RAM to run the software, not hold OS information?

Sorry for the rant, but it is hard to justify what I would consider short
comings of HORM to others when I can't justify them to myself.
 
Shawn,

Well, I guess the main "limitation" there of EWF Disk mode vs EWF RAM Reg is that by default the overlay data is "persistent".
The major reason for using EWF RAM for HORM scenario was that the changes you do while you work with the image that are redirected
to RAM are going to get lost on reboot. This way whatever OS does about the hibernation file (hiberfil.sys) will be lost as well and
you can always go back to the original state of the device.
With EWF Disk the changes are redirected to Disk overlay (another hidden partition on the disk) and EWF will pick them up at the
next boot until you clean the overlay or commit the changes (there is also a minor difference in behavior depending on what restore
level you selected for the disk mode but it is irrelevant to this discussion).

So, imagine the following scenario:
1) HORM is enabled. Hibernation file holds a valid state of the system saved at some point of time.
2) EWF is enabled too. Disk overlay is used. Initially the cache is *clean* (not really possible with EWF Disk mode when you
enable HORM but just for the sake of this explanation).
3) You boot the image and it boots fast from the hiberfil.sys file.
4) You work. FS (actually disk level) writes are redirected to Disk overlay, no files on the protected partition are actually
changed on the disk including the hiberfil.sys.
5) You reboot the system (gracefully or not).
6) The system boots from the same (old!) hiberfil.sys file. That means it will restore all the driver and application states to
whatever states they had in memory at the moment the golden image was hibernated. EWF driver also has some (old) state there where
it remembers what was the Disk overlay content at that time, i.e. it thinks the overlay is *clean* (see step#2).
However, your actual Disk Overlay is not clean since it was modified in an earlier OS session (see step#4). Now you get a
discrepancy between the disk overlay and its state in RAM (EWF state machine). This will likely lead to an exception within the EWF
driver and, since EWF is a kernel driver, to BSOD.

The situation is even worse if we go real and don't assume the *clean* initial state of the EWF overlay. Sine at the time we
hibernated the image the EWF was already enabled (it must be enabled) you already got some changes to the disk (often unintentional
such as logs, registry hive changes, etc.) that were redirected to the overlay.

Another issue could be that if you need to commit the changes (and stop the HORM) you won't be able to do that. The actual commit in
Disk overlay mode occurs at the next boot time when EWF driver reads all the changes off the hidden data partition and applies them
to the disk. Obviously, this happens way later than the OS (the loader and the kernel) loads the RAM image off the hiberfil.sys
(restores from the hibernation file). Since the hiberfil.sys file is the old one the EWF driver there (its state machine) doesn't
know the commit command was issued and you will never get out of the loop.

Hope this makes sense.

You may also want to read through this thread where we discussed the HORM feature implementations way before it was called HORM:
http://groups.google.com/group/micr...ad162b3d3b4b1b45?tvc=1&hl=en#ad162b3d3b4b1b45

In fact, to prove whether EWF Disk can theoretically be used with HORM you can try to use the hack to the loader (EWF loader in this
case) I mentioned in that thread.
 
Back
Top