Professional Documents
Culture Documents
Openstack
Openstack
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 ).
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.
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.
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)
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
| optional parameter
count
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.
If you want to use LUKS on-disk metadata with default cipher, use
cryptsetup luksFormat <device>
cryptsetup luksOpen <device> <name>