openstack

Concept Of Device Mapper Target Device mapper layer - explored Every storage system requires viewing the real disks in their own way. For example, if there are four disk and the system wants to create mirroring over them or concatenate them viewing them as a single big device or if there is one disk, then a particular system may want to encrypt all the data that is going to be stored on that disk i.e. all such systems want a logical layer of block devices on the top of existing underlying block devices and map the requests on this logical layer to underlying layer after doing particular processing at this layer. This facility is provided by device mapper. Device mapper can be defined as a generic way to add required functionality in the storage stack by creating virtual layer of block devices and mapping them to existing block devices. It create virtual layers of block devices that can do different things on top of existing underlying block devices like striping, concatenation, mirroring, snapshot, etc.The Device Mapper is a modular kernel driver that provides a generic framework for volume management. It has been introduced in the kernel version 2.6. The device-mapper is used by the LVM2 and EVMS 2.x tools. LVM is a tool which allows creating and managing partitions. The first version of LVM is in kernel 2.4 where there is no concept of device mapper. So, all the management of logical layer was the responsibility of LVM. But, due to the concept of device mapper in kernel 2.6, the logical layer management is done by device mapper and the code of LVM2 has been simplified to a great extent. This also brings modularity and reusability in the kernel. The concept of device mapper target: As stated above, we can create various logical layers through device mapper to carry out the required functionality. Each such layer is created by defining “a device mapper target” for that layer. There is one to one correspondence between a virtual layer at device mapper layer and the dm target for that layer.

The particular dm target contains the code which does the task of implementing functionality which the virtual layer intends to do. For example, a device mapper target can be written to implement mirroring over existing block devices. This dm target shows a virtual layer to upper layers which does the task of mirroring. Currently seven such features have been added to device mapper through seven device mapper targets. The device mapper targets are as follows: Linear This dm target allows us to concatenate number of disks to view them as a single big device or to view a part of disk as an individual logical disk. Thus, it creates a linear logical device on the top of existing block devices. RAID-0 / Striped The striped dm target is designed to handle striping across physical volumes i.e. to carry out well known RAID-0 functionality. RAID-1 / Mirrored RAID The mirrored dm target is designed to handle mirroring across number of disks. It carries out one of most famous RAID level functionality by creating and maintaining number of mirrors of data which all contain same data to improve reliability and speed of operations through load balancing. Snapshot This dm target carries out the functionality of snapshot and allows accessing the older versions of all files along with the latest one. DM-Crypt The dm-crypt device mapper target does the task of providing security through encrypting and decrypting of all the data that gets stored on the disk. Multipath In order to provide higher reliability for accessing the disks, this dm target provides a functionality of multipath so that in case of failure of path to disk, data on the disk can be accessed through alternative path. Zero The zero dm target returns all the data as zero for all the operations on the disk. Generally it is used for testing and to fill the gaps in new logical device. Error

The error dm target causes any I/O to the mapped disk to fail. This also is useful for defining gaps in the new logical device. Such device mapper target can be inserted into the kernel as a module and removed as per wish of the user. Or it can also be inserted into the kernel by creating its patch. Device mapper creates a logical layer of block devices and maps all the I/O requests on this logical layer to underlying existing block devices. For such mapping, device mapper uses a data structure called device mapper table. This table tells us how each and every sector (of size512 bytes) of a logical layer is mapped to a sector on underlying disk. Thus, each target carries out its functionality by doing I/O mapping using its corresponding device mapper table. So last but not least, Device mapper target represents a type of block device. Now the " ability to define the type of block device is provided by device mapper" so that is why it is generic layer. So when we want to provide a new type of block device with some advance functionality like snapshots, deduplication. we create new device mapper target, we write logic of the new functionality into that device mapper target.And we can create block devices of that device mapper target. (i.e new type of device ).

dm-crypt: Linux kernel device-mapper crypto target About dm-crypt Device-mapper is infrastructure in the Linux 2.6 and 3.x kernel that provides a generic way to create virtual layers of block devices. Device-mapper crypt target provides transparent encryption of block devices using the kernel crypto API. The user can basically specify one of the symmetric ciphers, an encryption mode, a key (of any allowed size), an iv generation mode and then the user can create a new block device in /dev. Writes to this device will be encrypted and reads decrypted. You can mount your filesystem on it as usual or stack dm-crypt device with another device like RAID or LVM volume. Basic documentation of dm-crypt mapping table comes with kernel source and the latest version is available in git repository.

To enable dm-crypt support, enable CONFIG_DM_CRYPT in Device Drivers/Multi-device support (RAID and LVM) configuration option. Most of distributions have dm-crypt included by default. To configure you need userspace components: device mapper library (part of LVM2 package) and cryptsetup. All these packages are usually included in your distro repository already. Check /proc/crypto which contains supported ciphers and modes (but note it contains only currently loaded crypto API modules). There is currently no better way how to list all available variations of cipher and modes if the crypto modules are not loaded.

Device mapper crypt table mapping line specification Mapping table in device mapper is defined like

•start_sector is 0 (for tables using only one mapped segment, iow table contains only one line) •size is size of device in sectors •target name is name of mapping target, here "crypt" for dm-crypt Sectors are always 512B sectors (even if device has bigger hw sector like 4k). Table fields are separated by space.

dm-crypt target version Every device-mapper target has internal version which is increased when some new feature is added. (With exceptions caused by developer's forgetfulness. ;-) To check which version you have installed, load the dm target module (dm-crypt.ko for dm-crypt) and use "dmsetup target" to check version. Note that crypt version target is not necessarily related to exact Linux kernel version, some distributions backport changes, so to check if some feature is implemented you need always check dm-crypt target version.

Mapping table for crypt target The basic syntax is common for all 1.x.y dm-crypt target versions. If some extension was added later, it is mentioned in the description. [ ]

•cipher: Encryption block cipher. Example: aes, twofish, serpent.

•keycount: Multi-key compatibility mode. You can define keycount keys and then sectors are encrypted according to their offsets (sector 0 uses key0, sector 1 uses key1 etc). keycount must be a power of two. This parameter is used for loop-AES compatibility mode. Available since: 1.10.0 (kernel 2.6.38)

•chainmode: Block cipher encryption mode. Example: cbc, xts.

•ivmode: Initialization Vector (IV) used for selected block mode (if block mode requires IV). Unless block ciphers and encryption modes, IV generators are implemented directly inside dm-crypt

module.

IV generators •plain: the initial vector is the 32-bit little-endian version of the sector number, padded with zeros if necessary.

•plain64: the initial vector is the 64-bit little-endian version of the sector number, padded with zeros if necessary. Available since: 1.7.0 (no proper version set) (kernel 2.6.33)

•essiv: "encrypted sector|salt initial vector", the sector number is encrypted with the bulk cipher using a salt as key. The salt is derived from the bulk cipher's key via hashing. ESSIV takes hash algorithm as option, so the format is essiv:hash, e.g. essiv:sha256. Available since: 1.1.0 (kernel 2.6.10)

•benbi: the 64-bit "big-endian 'narrow block'-count", starting at 1 Available since: 1.3.0 (no proper version set) (kernel 2.6.20)

•null: the initial vector is always zero. Provides compatibility with obsolete loop_fish2 devices. Available since: 1.5.0 (kernel 2.6.22)

•lmk: Compatible implementation of the block chaining mode used by the Loop-AES block device encryption system. Available since: 1.10.0 (kernel 2.6.38)

•tcw: Compatible implementation of the key seeded IV with additional whitening (to CBC mode) used by the TrueCrypt encryption system (prior to version 4.2). Available since: 1.13.0 (kernel 3.13) Examples of full cipher/mode/iv specifications: aes-cbc-essiv:sha256 aes-xts-plain64 aes:64-cbc-lmk twofish-ecb serpent-cbc-plain

•key: Key used for encryption. It is encoded as a hexadecimal number (one character represents 4 bits). You can only use key sizes that are valid for the selected cipher. For multikey mode are all keys of the same length concatenated to one string.

•iv_offset: The IV offset is a sector count that is added to the sector number before creating the IV. It can be used to create a map that starts after the first encrypted sector. Usually you'll set it to zero except your device is only partially available or you need to configure some mode compatible with other encryption system.

•device path: This is the device that is going to be used as backend and contains the encrypted data. You can specify it as a path like /dev/xxx or a device number major:minor.

•offset: Starting sector within the device where the encrypted data begins. •#opt_params: Number of optional parameters. If there are no optional parameters, the optional parameters section can be skipped or it can be zero. Otherwise it is the number of following arguments. Available since: 1.11.0 (kernel 3.1)

Optional parameters •allow_discards: Allow block discard requests (a.k.a. TRIM) for the crypt device. The default is to ignore discard requests. Assess the specific security risks carefully before enabling this option. For example, allowing discards on encrypted devices may lead to the leak of information about the ciphertext device (filesystem type, used space etc.) if the

discarded blocks can be located easily on the device later. Available since: 1.11.0 (kernel 3.1) Example of optional parameters section: 1 allow_discards

Example of full mapping table

0 417792 crypt aes-xts-plain64 e8cfa3dbfe373b536be43c5637387786c01be00ba5f730aacb039e86f3eb72f3 0 8:16 0 | | | | | | | | | | start| | | mode IV | | | offset size | cipher | | device target 256bit-key IV offset 0 417792 crypt serpent-cbc-essiv:sha256 a7f67ad520bd83b9725df6ebd76c3eee 0 /dev/sdb 0 | | | | | | | | | | | start| | | mode IV IV-opts | | | offset size | cipher | | device target 128bit-key IV offset Optional section example: 0 417792 crypt serpent-cbc-essiv:sha256 a7f67ad520bd83b9725df6ebd76c3eee 0 /dev/sdb 0 1 allow_discards |

|

| optional parameter count

Configuration with dmsetup tool Dmsetup is used to create and remove devices, get information about devices or reload tables (that means changing the mapping while the device is in use). Usually this tool is only used for low-level access to dm device, example here is mentioned just to show how the low level parameters works. Always prefer using cryptsetup if possible. To create device and specify mapping table, use dmsetup create --table " ..." command. The second example above is then created using dmsetup create x --table "0 $(blockdev --getsz /dev/sdb) crypt serpent-cbc-essiv:sha256 a7f67ad...ee 0 /dev/sdb 0"

You can check the full mapping table using dmsetup table with optional --showkeys parameter. Note that for all device-mapper operations is required root privilege (CAP_SYSADMIN). The newly created device then appears as /dev/mapper/name.

Configuration using cryptsetup cryptsetup utility support several modes. Plain mode is just equivalent of direct configuration of dmcrypt target with passphrase hashing but without on-disk metadata. LUKS (Linux Unified Key Setup) is now the preferred way to set up disk encryption with dm-crypt using the cryptsetup utility, see cryptsetup project page.

Example of using cryptsetup If you have keyfile (in binary format) in file /key, you can setup mapping in example above as

cryptsetup -d /key -s 128 -c serpent-cbc-essiv:sha256 create /dev/sdb

If you want to use LUKS on-disk metadata with default cipher, use cryptsetup luksFormat cryptsetup luksOpen