Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: Common block storage infrastructure techniques are described in which files are created through interaction with a file system to reserve extents in a volume on behalf of volume storage drivers, which may form a driver stack that resides logically on top of the volume. The files protect the reserved extents within the volume for use by the volume storage drivers, such as to store metadata related to operations performed by the drivers. When reserved extents are created, a location of the reserved extents is communicated through the driver stack to a corresponding volume storage driver. Volume storage drivers may also be configured to discover their corresponding reserved extents and communicate these to upper-level drivers and components. Accordingly, when a volume storage driver manipulates data in the volume, it may do so with awareness of the reserved extents of the other volume storage drivers.

Abstract: Full volume encryption can be applied to volumes in a clustering environment. To simplify the maintenance of keys relevant to such encrypted volumes, a cluster key table construct can be utilized, where each entry of the cluster key table corresponds to an encrypted volume and comprises an identification of the encrypted volume and a key needed to access that volume. Keys can be protected by encrypting them with a key specific to each computing device storing the cluster key table. Updates can be propagated among the computing devices in the cluster by first decrypting the keys and then reencrypting them with a key specific to each computing device as they are stored on those computing devices. Access control requirements can also be added to the entries in the cluster key table. Alternative access control requirements can be accommodated by assigning multiple independent entries to a single encrypted volume.

Abstract: Hardware encrypting storage devices can provide for hardware encryption of data being written to the storage media of such storage devices, and hardware decryption of data being read from that storage media. To utilize existing key management resources, which can be more flexible and accommodating, mechanisms for storing keys protected by the existing resources, but not the hardware encryption of the storage device, can be developed. Dedicated partitions that do not have corresponding encryption bands can be utilized to store keys in a non-hardware-encrypted manner. Likewise, partitions can be defined larger than their associated encryption bands, leaving room near the beginning and end for non-hardware encrypted storage. Or a separate bit can be used to individually specify which data should be hardware encrypted. Additionally automated processes can maintain synchronization between a partition table of the computing device and a band table of the hardware encrypting storage device.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by storing hashes of smaller portions of the module (e.g. page-level hashes) as they should look when loaded into memory for execution. After an initial authentication is completed, hashes of smaller portions of the module are stored. These hashes consist of the portion of memory as modified by changes which would be made by the operating system loader operating normally. Thus, the hashes can be used to verify that the portion as loaded into memory for execution is 1) a correct copy of the portion of the software module, 2) correctly modified for execution by the processor, and 3) not tampered with since loading.

Abstract: The import address table of a software module is verified in order to prevent detouring attacks. A determination is made regarding which entries in the IAT must be verified; all of the entries may be verified or some subset of the entries that are critical may be verified. For each external function, the external module containing the external function is loaded, if it is not already loaded. The function address in the exported function table is found. That address is compared to the address for the function in the IAT. Additionally, the external module, in one embodiment, is verified to ensure that it has not been modified. For a delay load IAT, a similar procedure is followed; however the delay load IAT may be periodically checked to ensure that the delay load IAT entries are either valid (indicating that the external function has been bound) or in their initial state (indicating that no binding has yet occurred).

Abstract: Full volume encryption can be applied to volumes in a clustering environment. To simplify the maintenance of keys relevant to such encrypted volumes, a cluster key table construct can be utilized, where each entry of the cluster key table corresponds to an encrypted volume and comprises an identification of the encrypted volume and a key needed to access that volume. Keys can be protected by encrypting them with a key specific to each computing device storing the cluster key table. Updates can be propagated among the computing devices in the cluster by first decrypting the keys and then reencrypting them with a key specific to each computing device as they are stored on those computing devices. Access control requirements can also be added to the entries in the cluster key table. Alternative access control requirements can be accommodated by assigning multiple independent entries to a single encrypted volume.

Abstract: Hardware encrypting storage devices can provide for hardware encryption of data being written to the storage media of such storage devices, and hardware decryption of data being read from that storage media. To utilize existing key management resources, which can be more flexible and accommodating, mechanisms for storing keys protected by the existing resources, but not the hardware encryption of the storage device, can be developed. Dedicated partitions that do not have corresponding encryption bands can be utilized to store keys in a non-hardware-encrypted manner. Likewise, partitions can be defined larger than their associated encryption bands, leaving room near the beginning and end for non-hardware encrypted storage. Or a separate bit can be used to individually specify which data should be hardware encrypted. Additionally automated processes can maintain synchronization between a partition table of the computing device and a band table of the hardware encrypting storage device.

Abstract: A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Abstract: Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by using pre-computed portion-level verification data for portions of the module smaller than the whole (e.g. at the page-level). A portion of the module as loaded into memory for execution can be verified. Pre-computed portion-level verification data is retrieved from storage and used to verify the loaded portions of the executable. Verification data may be, for example, a digitally signed hash of the portion. Where the operating system loader has modified the portion for execution, the modifications are reversed, removing any changes performed by the operating system. If the portion has not been tampered, this will return the portion to its original pre-loaded state. This version is then used to determine validity using the pre-computed portion-level verification.

Abstract: Common block storage infrastructure techniques are described in which files are created through interaction with a file system to reserve extents in a volume on behalf of volume storage drivers, which may form a driver stack that resides logically on top of the volume. The files protect the reserved extents within the volume for use by the volume storage drivers, such as to store metadata related to operations performed by the drivers. When reserved extents are created, a location of the reserved extents is communicated through the driver stack to a corresponding volume storage driver. Volume storage drivers may also be configured to discover their corresponding reserved extents and communicate these to upper-level drivers and components. Accordingly, when a volume storage driver manipulates data in the volume, it may do so with awareness of the reserved extents of the other volume storage drivers.

Abstract: Run-time call stack verification is used to determine that a code module has been called by a legitimate caller. A return address on the stack indicates where execution is to return upon execution of the next return instruction, and this return address is indicative of where the code module was called from. The code module may determine that the call is allowed, or disallowed, based on the location of the return address. A calling convention is provided that allows the code module to be called through an intermediary, while also preserving the original return address that was in effect at the time the intermediary was called and also resisting modification to the call stack during the time that the original return address is being verified.

Abstract: Dynamic run-time verification of a module which is loaded in memory (in whole or in part) for execution is enabled by using pre-computed portion-level verification data for portions of the module smaller than the whole (e.g. at the page-level). A portion of the module as loaded into memory for execution can be verified. Pre-computed portion-level verification data is retrieved from storage and used to verify the loaded portions of the executable. Verification data may be, for example, a digitally signed hash of the portion. Where the operating system loader has modified the portion for execution, the modifications are reversed, removing any changes performed by the operating system. If the portion has not been tampered, this will return the portion to its original pre-loaded state. This version is then used to determine validity using the pre-computed portion-level verification.

Abstract: Run-time call stack verification is used to determine that a code module has been called by a legitimate caller. A return address on the stack indicates where execution is to return upon execution of the next return instruction, and this return address is indicative of where the code module was called from. The code module may determine that the call is allowed, or disallowed, based on the location of the return address. A calling convention is provided that allows the code module to be called through an intermediary, while also preserving the original return address that was in effect at the time the intermediary was called and also resisting modification to the call stack during the time that the original return address is being verified.

Abstract: The import address table of a software module is verified in order to prevent detouring attacks. A determination is made regarding which entries in the IAT must be verified; all of the entries may be verified or some subset of the entries that are critical may be verified. For each external function, the external module containing the external function is loaded, if it is not already loaded. The function address in the exported function table is found. That address is compared to the address for the function in the IAT. Additionally, the external module, in one embodiment, is verified to ensure that it has not been modified. For a delay load IAT, a similar procedure is followed; however the delay load IAT may be periodically checked to ensure that the delay load IAT entries are either valid (indicating that the external function has been bound) or in their initial state (indicating that no binding has yet occurred).