Disk Protection in Windows XP Embedded Feature Pack 2007

8/22/2007

Alexander Wechsler, Wechsler Consulting GmbH & Co. KG, www.wechsler-consulting.de

February 2007

Summary

The Feature Pack 2007 CTP allows us to have a first look at its improvements and new functionality regarding disk protection for systems built with Microsoft® Windows® XP Embedded SP2. This article sheds light on what has changed for technologies already available as well as on new possibilities that will be coming, when the feature pack is released.

Applies To

Windows XP Embedded SP2 Feature Pack 2007 Community Technology Preview (CTP)

Introduction

So, What Is New Concerning Disk Protection?

Enhanced Write Filter

File Based Write Filter

Registry Filter

Being Good Neighbors – Disk Protection Mechanisms Side-By-Side

Conclusion

See Also

Introduction

Disk protection, also known as Enhanced Write Filter (EWF), has been available since SP1 in XP embedded. It has been a very useful technology, to save compact flash cards from facing a sudden death through too many write cycles. It also added more robustness in, for example, kiosk systems that could get rid of viruses and worms easily by being simply rebooted.

This sounds great (and it is), so why improve and add new features, one could ask?

Well, while being quite protective, EWF is not ideal for all scenarios, that can be encountered in a special purpose device’s life cycle and it is currently not easy to configure under all circumstances.

Due to this, the Microsoft product team uses the Feature Pack to iron out a lot of those painful inconveniences. FP 07 is also used to roll out new filters that supplement the Enhanced Write Filter use cases, while adding other important usage scenarios.

So, What Is New Concerning Disk Protection?

From a birds eye view the quick facts: The Enhanced Write Filter has undergone an overhaul especially targeted at its configuration and management functionality as well as the accompanying tools.

Then there is a set of new filters: The File Based Write Filter (FBWF) and the Registry Filter. These filters solve quite a lot of the issues EWF was able to satisfy or simply by its architecture not intended to do so.

Let’s have a closer look at the details.

Enhanced Write Filter

The Enhanced Write Filter is a filter driver sitting between the file system and the disk driver. It works on disk sector level and this means that it redirects changed sectors to a new location called an overlay. The filter is not aware of any file system specifics. Due to this, persisting a certain file through it to the underlying image directly (without turning it off) requires the file having a fixed size (claiming always the same sectors on the disk drive). This is the reason for some of the limitations that are experienced using EWF.

EWF’s possible overlay modes come in three flavors disk, RAM and RAM (Reg). While disk overlay is able to generate up to seven overlays on a special overlay partition, the two RAM modes are only capable of holding a single overlay, which is volatile by the nature of the storage medium (RAM). The difference between these two modes is, that RAM overlay, like disk overlay, requires an additional EWF partition on the storage medium to hold the EWF partition table data. This additional partition is not easy to handle, looking at factory install processes as well as maintenance.

Microsoft has introduced another mode to target this problem with Service Pack 2 called RAM (Reg). In this mode the EWF partition table info is stored in the registry instead on a special partition, which simplifies deployment a lot.

However, RAM (Reg), due to its lack of integration into the XPe tools, felt like a kind of secret mode, because getting it to work required quite some manual work by the OS developer.

With the Feature Pack 2007 these times are gone! As shown in figure 1, RAM (Reg) mode is now a first class citizen of the EWF world.

Bb331823.6b1b0ed7-a951-4d9d-8eb5-57ea69256493(en-US,WinEmbedded.5).bmp

Figure 1. New EWF component configuration settings

This eliminates, for example, the need to build custom components containing the RAM (Reg) registry keys and to disable FBEReg.dll COM registration in the EWF component resources. Additionally there is new functionality available, such as turning of background disk defragmentation to avoid the overflow of RAM overlays.

While building such a configuration, not including system restore, not using a page file as well as fine tuning the write access of the NTFS file system could be added as best practices.

Even HORM can be activated in the EWF component now, saving a lot of manual work on the way to generate the “Golden Image” that can be cloned on the target devices.

HORM - Hibernate Once Resume Many

Enables a robust boot scenario using a one-time created hibernation file from which the system always boots.

This enables the creation of fast (below 10 seconds are possible!) booting as well as robust devices. Even after power failures these systems come up quick and without damages to the file system (well, it is protected).

HORM requires RAM or RAM (Reg) overlay and can only be configured using EWF. Disk overlay is not possible because the state once persisted in the hibernation file must not get out of sync with the state on the protected partition.

Due to the fact that EWF and HORM are tightly related, both now can be managed by the EWF manager command-line utility using the ActivateHORM or DeactivateHorm commands. These changes are also reflected in the new version of the EWF API that enables access to the same functionality as the command-line utility for applications.

File Based Write Filter

The File Based Write Filter acts as a filter driver above the file system driver and therefore has much more capabilities handling files than the sector-based EWF ever had. It uses RAM / RAM (REG) as its only two overlay modes and does not require a special FBWF partition.

From a user mode application’s perspective, the driver running in kernel mode is completely transparent, meaning that no application needs to be aware that it uses FBWF, at any time.

FBWF itself distinguishes two different persistence scenarios: One is “Selective Write Through”, which persists changes of a selected file immediately and transparently to the protected volume and the other is “Selective Commit and Restore”, which commits a file from the overlay to the protected volume. The later, of course, must be initiated somehow, either by an application itself (via the FBWF API) or via the FBWF command-line utility called manually or by script.

Doing a “Selective Restore” means to reestablish the version from the protected volume into the overlay.

And unfortunately, there are some things that can create problems, for example if the application moves files from a protected to an unprotected volume or if the application generates an overflow in the RAM overlay, that might very well come unexpected. These things result in error states that need to be handled.

From a security perspective, applications developers should also be aware that files in the overlay are not encrypted. Additionally, does FBWF only work on NTFS and FAT32. FAT16, FAT12, or Flash file systems are not supported. It is also only able to protect already formatted volumes. Unformatted volumes cannot be detected.

However, the most interesting feature of FBWF is the ability to commit files or directories through the running filter without restarting it or having an eye on the file size as with EWF. This works fine with files that have already been existing before turning on FBWF is turned on, but one has to be aware that committing new or deleted files may cause errors!

To add FBWF functionality, one has to add the File Based Write Filter component to the XP embedded image. Then FBWF can be configured via the component property pages as shown in the following figure.

Bb331823.05c7ea59-6e4b-4c49-96ea-0047fa4b7504(en-US,WinEmbedded.5).bmp

Figure 2. FBWF component properties

The component settings allow to, turn on/off FBWF after FBA, and choose the type of a dynamically growing or fixed overlay, while also specifying a maximum boundary for the RAM overlay. OS developers then can opt to enable the write protection best practices already mentioned for EWF and of course are able to select which files and/or directories should be protected on which drives.

To configure more than one volume, just specify the intended number of protected volumes and the required property pages will become accessible via the prev/next buttons at the bottom of the page.

In addition to this design-time configuration approach, the selective write through settings can be altered via the FBWF Manager command-line utility and the FBWF API directly from an application.

FBWF manager as well as the API offers access to the following functionalities:

  • Disabling/enabling File Based Write Filtering
  • Setting/querying cache memory usage
  • Setting/querying compression usage
  • Enable/disable write filtering for an entire volume
  • Excluding a file or directory from write filtering.
  • Committing/restoring cache contents to or from the actual file

Bb331823.f1cbcbdc-807b-474f-b04e-b070b3fb2238(en-US,WinEmbedded.5).bmp

Figure 3. FBWF Manager command help

While running, FBWF tries to optimize its cache by freeing memory, for example if files get deleted or shrink in size.

Registry Filter

One major problem EWF has had until now is the persistence of the computer account password in the registry on a protected volume while participating in a domain. This password is automatically changed by Active Directory at least every 30 days and needs to be stored in the registry. One of the current workarounds is to turn off EWF, change the machine account password and then turn on EWF again.

This is not a really convenient way to handle the problem.

Quite similar is the case for acquiring the secrets needed to participate in a terminal server session (CAL – Client Access License). Here EWF needs to be turned off to store the CAL secret at least once, during the first connect to the terminal server.

But now, there is help! The registry filter solves this issues bypassing EWF or FBWF to write through selected registry keys.

In the current CTP the registry filter component property page allows to enable write through for Domain Participation and TSCAL persistence. But, one is able to extend the range of monitored registry keys by manually editing the registry key shown here.

Bb331823.b7a91355-58a3-4da7-b86c-3cabfb17a353(en-US,WinEmbedded.5).bmp

Figure 4. Registry settings to extend monitored key for registry filter

If you extend the Monitored Keys registry key with a new key numbered in order and specifies a suited ClassKey (HKLM, and so on), RelativeKeyname (your key relative to the class) and a FileNameForSaving having the extension .rgf, then at least with the current CTP bits this key is treated as “write through” as well.

The preceding sample shows the custom key HKLM\System\CurrentControlSet\Control\Alex being added to the list of monitored keys. It the can be directly written through the EWF or FBWF.

It would be very good if Microsoft would extend the component configuration UI to give direct access to this powerful functionality with the release of Feature Pack 2007.

The registry filter currently does not provide a command-line utility or API for management but could be maintained by changing its registry settings using the Microsoft Registry Editor (Regedit.exe) or an application.

Being Good Neighbors – Disk Protection Mechanisms Side-By-Side

With the arrival of two new disk protection filter technologies not only functionality, but also complexity rises.

How do combinations of the different technologies work together?

The Registry Filter to this respect is the easiest one. It can be used with EWF or FBWF just by adding the component and configuring it correctly.

Looking at the remaining two, choice is getting a little more difficult.

At first, EWF and FBWF cannot protect the same volume, but they are able to coexist on the same machine without any problem. For example, protect the OS partition with EWF and a data partition with FBWF to allow database files to be written through the filter.

If you want to leverage HORM, EWF needs to be used at least for the boot partition. The benefits of FBWF clearly are defined by its file handling and its improved memory handling capabilities. But it is always good to know, that FBWF is not capable of having more than one overlay on disk or doing a complete commit of the complete overlay onto the protected volume such as provided by the EWF commitanddisable –live command. In addition and unlike EWF, FBWF does not support the following NTFS features:

  • File locking and unlocking
  • File ID in NTFS
  • Reparse points
  • Quota
  • Hard links
  • Opportunistic lock
  • File compression and encryption

So, from this point of view, the decision, when to use which XPe disk protection technology, should be based on the requirements of the use case the embedded device is built for.

Conclusion

Windows XP Embedded Feature Pack 2007 delivers great new functionality especially looking at disk protection for Windows Embedded devices.

A lot of work has been done to solve some of the most urgent problems using this technology, as well. The significant enhancements to the Enhanced Write Filter will speed up development time significantly. It also will make it easier to use and maintain valuable functionality such as HORM. The registry filter solves important problems regarding Domain Participation and Terminal Server usage and can be used for custom purposes, as well.

The File Based Write Filter creates a wealth of new possibilities on systems where EWF has not been granular enough or too inefficient to handle.

But overall, none of the technologies should be treated as a single entity. They all can provide best benefits, if used together in combinations, for example, as described using EWF protecting the OS partition and providing HORM boot abilities, while FBWF protecting the other partitions allowing only the selected files to be written to by applications having the correct security settings. In such a scenario the Registry Filter could be used to provide seamless domain integration.

See Also

Other Resources

http://msdn.microsoft.com/embedded/