dm-verity / dm-integrity / dm-crypt — Device Mapper 데이터 검증, 무결성(Integrity), 암호화(Encryption)

Linux Device Mapper는 블록 디바이스 위에 가상 레이어를 쌓아 데이터 검증(dm-verity), 무결성 보호(dm-integrity), 암호화(dm-crypt)를 투명하게 제공합니다. Android Verified Boot의 핵심인 dm-verity Merkle Tree, 저널링(Journaling) 기반 dm-integrity, LUKS/dm-crypt 블록 암호화, 그리고 이들의 결합(AEAD)까지 커널 내부 구현(drivers/md/)을 심층 분석합니다.

Device Mapper 개요

Device Mapper(DM)는 Linux 커널의 블록 레이어에서 가상 블록 디바이스를 생성하는 프레임워크입니다. drivers/md/dm.c에 구현된 DM 코어는 struct mapped_device로 가상 디바이스를 표현하고, struct dm_table로 매핑 테이블을 관리합니다. 각 target 드라이버(struct target_type)는 특정 기능(암호화, 검증, 스냅샷 등)을 구현하며, DM 코어가 bio를 적절한 target에 라우팅(Routing)합니다.

DM은 원래 Heinz Mauelshagen이 LVM(Logical Volume Manager)을 위해 개발했으며, 현재는 dm-crypt, dm-verity, dm-integrity, dm-thin, dm-cache, dm-snapshot 등 다양한 target을 통해 리눅스 스토리지 스택의 핵심 계층으로 자리잡았습니다. 사용자 공간(User Space)에서는 dmsetup, cryptsetup, veritysetup, integritysetup 등의 도구로 DM 디바이스를 관리합니다.

DM 코어의 핵심 자료 구조를 살펴봅니다:

/* include/linux/device-mapper.h */
struct target_type {
    uint64_t features;
    const char *name;
    struct module *module;

    int (*ctr)(struct dm_target *ti, unsigned argc, char **argv);
    void (*dtr)(struct dm_target *ti);
    int (*map)(struct dm_target *ti, struct bio *bio);
    int (*end_io)(struct dm_target *ti, struct bio *bio,
                  blk_status_t *error);
    void (*status)(struct dm_target *ti, status_type_t type,
                   unsigned status_flags, char *result,
                   unsigned maxlen);
    int (*iterate_devices)(struct dm_target *ti,
                          iterate_devices_callout_fn fn, void *data);
};

struct dm_target {
    struct dm_table *table;
    struct target_type *type;
    sector_t begin;          /* 매핑 시작 섹터 */
    sector_t len;            /* 매핑 길이 (섹터) */
    void *private;           /* target 별 사적 데이터 */
    unsigned num_discard_bios;
    unsigned num_secure_erase_bios;
    unsigned num_write_zeroes_bios;
};

DM의 I/O 경로는 다음과 같이 진행됩니다: 사용자 공간에서 가상 디바이스(/dev/dm-N)에 I/O를 발행하면, dm_submit_bio()가 호출됩니다. 이 함수는 dm_table에서 bio가 속하는 target을 찾아 해당 target의 map() 콜백(Callback)을 호출합니다. target은 bio를 변환(remap, split, encrypt 등)하여 하위 디바이스로 전달합니다. map() 콜백의 반환값에 따라 DM 코어가 bio의 후속 처리를 결정합니다: DM_MAPIO_REMAPPED는 bio가 하위 디바이스로 redirect되었음을, DM_MAPIO_SUBMITTED는 target이 bio를 완전히 처리했음을 의미합니다.

/* drivers/md/dm-ioctl.c - 주요 ioctl 명령 */
/* 사용자 공간 (dmsetup) <-> 커널 DM 인터페이스 */

/* DM_DEV_CREATE: 새 mapped_device 생성 */
/* DM_DEV_REMOVE: mapped_device 제거 */
/* DM_TABLE_LOAD: 매핑 테이블 로드 */
/* DM_DEV_SUSPEND: I/O 일시 중지 (테이블 교체 준비) */
/* DM_DEV_STATUS: 디바이스 상태 조회 */
/* DM_TABLE_STATUS: 테이블 상태 (dmsetup status) */
/* DM_TARGET_MSG: target에 메시지 전달 (dmsetup message) */

static int table_load(struct file *filp,
                      struct dm_ioctl *param,
                      size_t param_size)
{
    struct dm_table *t;
    struct mapped_device *md;

    /* 1. 테이블 생성 */
    r = dm_table_create(&t, get_mode(param), param->target_count, md);

    /* 2. 각 target 파싱 및 추가 */
    for (i = 0; i < param->target_count; i++) {
        dm_table_add_target(t, type_name, start, len, params);
        /* 내부에서 target_type->ctr() 호출 */
    }

    /* 3. 테이블 완료 (무결성 검증) */
    r = dm_table_complete(t);

    /* 4. 테이블을 mapped_device에 연결 */
    dm_swap_table(md, t);
    return 0;
}

/* bio 라우팅 - dm_submit_bio() 핵심 경로 */
static void dm_submit_bio(struct bio *bio)
{
    struct mapped_device *md = bio->bi_bdev->bd_disk->private_data;
    struct dm_table *map;
    struct dm_target *ti;

    map = dm_get_live_table(md, &srcu_idx);

    /* bio가 속하는 target 찾기 */
    ti = dm_table_find_target(map, bio->bi_iter.bi_sector);

    /* target의 map() 콜백 호출 */
    r = ti->type->map(ti, bio);

    switch (r) {
    case DM_MAPIO_SUBMITTED:
        break;  /* target이 처리 완료 */
    case DM_MAPIO_REMAPPED:
        submit_bio_noacct(bio);  /* 하위 디바이스로 전달 */
        break;
    case DM_MAPIO_REQUEUE:
        bio_io_error(bio);  /* 재시도 */
        break;
    }

    dm_put_live_table(md, srcu_idx);
}

dm-verity 개요

dm-verity는 읽기 전용 블록 디바이스의 무결성을 검증하는 Device Mapper target입니다. ChromeOS에서 최초 도입되어 Android Verified Boot(AVB)의 핵심 메커니즘으로 자리잡았습니다. 커널 소스 drivers/md/dm-verity-target.c에 구현되어 있으며, 빌드 시점에 생성된 Merkle Tree의 루트 해시를 런타임에 블록 단위로 검증합니다.

dm-verity의 핵심 원리는 간단합니다: 디스크의 모든 4KB 블록에 대해 SHA-256(또는 다른 해시) 값을 계산하고, 이 해시들을 다시 해싱하여 트리 구조를 만듭니다. 최종 루트 해시 하나만 신뢰할 수 있으면 전체 디스크의 무결성을 검증할 수 있습니다. 읽기 요청이 들어올 때마다 해당 블록의 해시를 Merkle Tree에서 확인하여 변조를 탐지합니다.

/* drivers/md/dm-verity.h */
struct dm_verity {
    struct dm_dev *data_dev;       /* 데이터 디바이스 */
    struct dm_dev *hash_dev;       /* 해시 트리 디바이스 */
    struct dm_target *ti;
    struct dm_verity_fec *fec;    /* FEC 옵션 */

    unsigned int data_dev_block_bits;  /* 데이터 블록 크기 비트 */
    unsigned int hash_dev_block_bits;  /* 해시 블록 크기 비트 */
    unsigned int hash_per_block_bits;  /* 블록당 해시 수 비트 */
    unsigned int levels;              /* 트리 레벨 수 */
    unsigned int digest_size;          /* 해시 출력 크기 */
    unsigned int salt_size;

    const char *alg_name;              /* "sha256" 등 */
    u8 *root_digest;                   /* 루트 해시 */
    u8 *salt;                           /* salt 값 */
    sector_t data_blocks;              /* 총 데이터 블록 수 */
    sector_t hash_start;               /* 해시 영역 시작 */
    sector_t hash_blocks;              /* 해시 블록 수 */

    enum verity_mode mode;  /* EIO, logging, restart, panic */
    unsigned int validated_blocks;
    struct workqueue_struct *verify_wq;
};

Merkle Tree 구조

dm-verity의 Merkle Tree는 데이터 블록들의 해시를 계층적으로 구성합니다. 리프(leaf) 레벨에서 각 데이터 블록(4KB)의 해시(SHA-256 기준 32바이트)를 계산하고, 이 해시들을 하나의 해시 블록(역시 4KB)에 모아 다시 해싱합니다. 4KB 블록에 32바이트 해시가 128개 들어가므로, 각 레벨에서 팬아웃(fan-out)은 128입니다. 1GB 데이터의 경우 SHA-256 기준으로 약 8MB + 64KB + 512B + 32B = 약 8.06MB의 해시 공간이 필요하며, 이는 전체 데이터의 약 0.8%에 불과합니다.

/* Merkle Tree 레벨별 블록 수 계산 (커널 내부) */
/* drivers/md/dm-verity-target.c: verity_ctr() */
static int verity_hash_levels(struct dm_verity *v)
{
    sector_t hash_position;
    int levels = 0;
    sector_t data_blocks = v->data_blocks;

    /* hash_per_block = 블록_크기 / digest_size
     * SHA-256, 4KB 블록: 4096/32 = 128 */
    while (data_blocks > 1) {
        data_blocks = DIV_ROUND_UP(data_blocks,
                     1 << v->hash_per_block_bits);
        levels++;
    }
    v->levels = levels;

    /* 각 레벨의 해시 블록 시작 위치 계산 */
    hash_position = 0;
    for (int i = levels - 1; i >= 0; i--) {
        v->hash_level_block[i] = hash_position;
        data_blocks = DIV_ROUND_UP(v->data_blocks,
                     (sector_t)1 << (v->hash_per_block_bits * (i + 1)));
        hash_position += data_blocks;
    }
    return 0;
}

dm-verity 설정

dm-verity를 설정하려면 먼저 veritysetup 도구로 Merkle Tree를 생성하고, 이를 DM 테이블에 로드합니다. veritysetup은 cryptsetup 패키지에 포함되어 있습니다. 설정 과정은 오프라인 해시 생성과 온라인 검증 활성화 2단계로 나뉩니다.

# 1. 데이터 디바이스에 대한 해시 트리 생성
$ veritysetup format /dev/sda1 /dev/sda2
VERITY header information for /dev/sda2
UUID:            a1b2c3d4-e5f6-7890-abcd-ef1234567890
Hash type:       1
Data blocks:     262144
Data block size: 4096
Hash block size: 4096
Hash algorithm:  sha256
Salt:            abcdef0123456789abcdef0123456789...
Root hash:       4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d...

# 2. dm-verity 디바이스 활성화
$ veritysetup open /dev/sda1 verified_root /dev/sda2 \
    4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d...

# 3. 읽기 전용으로 마운트
$ mount -o ro /dev/mapper/verified_root /mnt/verified

# 4. dmsetup으로 직접 설정하는 경우
$ echo "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 \
    262144 1 sha256 \
    4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d... \
    abcdef0123456789abcdef0123456789..." | dmsetup create verified_root

커널 내부 구현

dm-verity의 커널 구현은 drivers/md/dm-verity-target.c에 있습니다. 핵심 함수는 verity_map()과 verity_end_io()이며, 워크큐 기반으로 해시 검증을 수행합니다. 읽기 bio가 도착하면 verity_map()이 bi_end_io를 교체하고 데이터 디바이스로 remap합니다. 데이터 읽기가 완료되면 verity_end_io()가 워크큐에서 해시 검증을 스케줄합니다.

/* drivers/md/dm-verity-target.c */
static int verity_map(struct dm_target *ti, struct bio *bio)
{
    struct dm_verity *v = ti->private;
    struct dm_verity_io *io;

    /* 쓰기 요청은 거부 (읽기 전용) */
    if (bio_data_dir(bio) == WRITE) {
        bio->bi_status = BLK_STS_IOERR;
        bio_endio(bio);
        return DM_MAPIO_SUBMITTED;
    }

    io = dm_per_bio_data(bio, ti->per_io_data_size);
    io->v = v;
    io->orig_bi_end_io = bio->bi_end_io;
    io->block = bio->bi_iter.bi_sector >> (v->data_dev_block_bits - SECTOR_SHIFT);
    io->n_blocks = bio->bi_iter.bi_size >> v->data_dev_block_bits;

    bio->bi_end_io = verity_end_io;
    bio_set_dev(bio, v->data_dev->bdev);
    verity_prefetch_io(v, io);

    return DM_MAPIO_REMAPPED;
}

static void verity_end_io(struct bio *bio)
{
    struct dm_verity_io *io = dm_per_bio_data(bio, ...);

    if (bio->bi_status) {
        verity_finish_io(io, bio->bi_status);
        return;
    }

    INIT_WORK(&io->work, verity_work);
    queue_work(io->v->verify_wq, &io->work);
}

verity_verify_io()는 각 데이터 블록에 대해 bottom-up으로 Merkle Tree를 순회합니다: 데이터 블록의 해시를 계산하고, 이를 Level 0 해시와 비교한 뒤, Level 0 해시 블록의 해시를 Level 1과 비교하는 방식으로 루트까지 올라갑니다. 한 번 검증된 해시 블록은 dm_bufio 캐시에 보관되어 재검증을 피합니다.

/* drivers/md/dm-verity-target.c - verity_verify_io() 핵심 */
static int verity_verify_io(struct dm_verity_io *io)
{
    struct dm_verity *v = io->v;
    struct bvec_iter start;
    unsigned int b;

    for (b = 0; b < io->n_blocks; b++) {
        int r;
        sector_t cur_block = io->block + b;
        struct ahash_request *req = verity_io_hash_req(v, io);

        /* 1단계: 데이터 블록 해시 계산 */
        r = verity_hash_for_block(v, io, cur_block,
                                  verity_io_want_digest(v, io),
                                  &is_zero);
        if (unlikely(r < 0))
            return r;

        /* 2단계: Merkle Tree 검증 (bottom-up) */
        r = verity_verify_level(v, io, cur_block, 0,
                               verity_io_want_digest(v, io));
        if (r)
            return r;
    }
    return 0;
}

/* 해시 블록 prefetch - 성능 최적화 핵심 */
static void verity_prefetch_io(struct dm_verity *v,
                               struct dm_verity_io *io)
{
    int i;

    for (i = v->levels - 1; i >= 0; i--) {
        sector_t hash_block_start, hash_block_end;

        /* 이 bio가 접근할 해시 블록 범위 계산 */
        hash_block_start = io->block >> (v->hash_per_block_bits * (i + 1));
        hash_block_end = (io->block + io->n_blocks - 1) >>
                         (v->hash_per_block_bits * (i + 1));

        hash_block_start += v->hash_level_block[i];
        hash_block_end += v->hash_level_block[i];

        /* dm_bufio를 통해 비동기 prefetch */
        dm_bufio_prefetch(v->bufio, hash_block_start,
                          hash_block_end - hash_block_start + 1);
    }
}

/* dm-verity target 등록 - 모듈 초기화 */
static struct target_type verity_target = {
    .name    = "verity",
    .version = {1, 9, 0},
    .module  = THIS_MODULE,
    .ctr     = verity_ctr,
    .dtr     = verity_dtr,
    .map     = verity_map,
    .status  = verity_status,
    .prepare_ioctl = verity_prepare_ioctl,
    .iterate_devices = verity_iterate_devices,
    .io_hints = verity_io_hints,
};

/* verity_ctr() 주요 파라미터 파싱 */
static int verity_ctr(struct dm_target *ti,
                      unsigned int argc, char **argv)
{
    struct dm_verity *v;
    int r, i;
    unsigned int num;

    v = kzalloc(sizeof(*v), GFP_KERNEL);
    v->ti = ti;

    /* argv[0]: version
     * argv[1]: data_dev
     * argv[2]: hash_dev
     * argv[3]: data_block_size
     * argv[4]: hash_block_size
     * argv[5]: num_data_blocks
     * argv[6]: hash_start_block
     * argv[7]: algorithm
     * argv[8]: root_hash
     * argv[9]: salt (또는 "-") */

    r = dm_get_device(ti, argv[1], FMODE_READ, &v->data_dev);
    r = dm_get_device(ti, argv[2], FMODE_READ, &v->hash_dev);

    /* Crypto API로 해시 알고리즘 할당 */
    v->tfm = crypto_alloc_ahash(argv[7], 0, 0);
    v->digest_size = crypto_ahash_digestsize(v->tfm);

    /* Merkle Tree 레벨 계산 */
    verity_hash_levels(v);

    /* dm_bufio 클라이언트 생성 (해시 블록 캐시) */
    v->bufio = dm_bufio_client_create(v->hash_dev->bdev,
                1 << v->hash_dev_block_bits, 1, 0,
                NULL, NULL, 0);

    /* 검증 워크큐 생성 */
    v->verify_wq = alloc_workqueue("kverityd",
                    WQ_CPU_INTENSIVE | WQ_MEM_RECLAIM, num_online_cpus());

    /* 선택적 파라미터: FEC, check_at_most_once 등 */
    r = verity_parse_opt_args(ti, v, argc - 10, argv + 10);

    ti->private = v;
    return 0;
}

dm-verity의 성능 특성을 이해하는 것이 중요합니다. 각 4KB 데이터 블록을 읽을 때마다 SHA-256 해시 1회 + Merkle Tree 레벨 수만큼의 추가 해시 검증이 필요합니다. 단, dm_bufio 캐시 덕분에 상위 레벨 해시 블록은 대부분 캐시 히트되며, 실질적인 오버헤드는 리프 레벨 해시 1회 + 해시 블록 읽기 1-2회 정도입니다. SHA-256의 소프트웨어 처리량(Throughput)은 약 500MB/s이며, SHA-NI 하드웨어 가속 시 2-3GB/s까지 향상됩니다.

Android Verified Boot

Android Verified Boot(AVB)는 dm-verity를 기반으로 시스템 파티션의 무결성을 보장합니다. AVB 2.0(libavb)은 부트로더에서 vbmeta 파티션을 검증하고, vbmeta에 포함된 dm-verity 루트 해시를 커널의 dm-verity target에 전달합니다. 이 체인을 통해 부트로더 → 커널 → 시스템 파티션까지 전체 부팅 경로의 무결성이 보장됩니다.

# Android 디바이스에서 dm-verity 상태 확인
$ adb shell dmctl list devices
system-verity     : active
vendor-verity     : active

# vbmeta 구조 확인
$ avbtool info_image --image vbmeta.img
Header Block:           256 bytes
Authentication Block:   576 bytes
Algorithm:              SHA256_RSA4096
Rollback Index:         1
Descriptors:
  Hashtree descriptor:
    dm-verity Version:  1
    Image Size:         3221225472 bytes
    Tree Offset:        3221225472
    Tree Size:          25427968
    Data Block Size:    4096
    Hash Algorithm:     sha256
    FEC num roots:      2
    Root Digest:        abc123...

# Android dm-verity 커맨드라인 (init에서 파싱)
# 부트로더가 커널 cmdline에 삽입하는 dm-verity 파라미터
androidboot.veritymode=enforcing
dm="1 vroot none ro 1,
    0 6291456 verity 1
    PARTUUID=a1b2c3d4 PARTUUID=e5f6g7h8
    4096 4096 786432 786433 sha256
    4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b
    0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
    10 restart_on_corruption ignore_zero_blocks use_fec_from_device
    PARTUUID=i9j0k1l2 fec_roots 2 fec_blocks 786432 fec_start 786432"

# Android init에서 dm-verity 설정 과정
# 1. first_stage_init: 부트 이미지에서 fstab 로드
# 2. fs_mgr: fstab의 verify 옵션 파싱
# 3. fs_mgr_setup_verity(): dm-verity 테이블 생성
# 4. dm_ioctl(DM_TABLE_LOAD): 커널에 테이블 로드
# 5. dm_ioctl(DM_DEV_SUSPEND): 디바이스 활성화
# 6. mount(): 검증된 디바이스 마운트

# Android fstab.device 예시
# system  /system  ext4  ro,barrier=1  wait,verify,first_stage_mount
# vendor  /vendor  ext4  ro,barrier=1  wait,verify,first_stage_mount

# vbmeta에 rollback protection 인덱스 설정
$ avbtool make_vbmeta_image     --output vbmeta.img     --key /path/to/key.pem     --algorithm SHA256_RSA4096     --rollback_index 3     --chain_partition system:1:/path/to/system_key.avbpubkey     --chain_partition vendor:2:/path/to/vendor_key.avbpubkey

Android 12+에서는 File-Based Encryption(FBE)이 기본이며, dm-default-key target으로 메타데이터 암호화를 추가합니다. 기존의 Full-Disk Encryption(FDE, dm-crypt 단일)은 deprecated되었습니다. FBE는 각 사용자의 CE(Credential Encrypted) 키와 DE(Device Encrypted) 키를 분리하여, 잠금 화면에서도 알람이나 전화 수신이 가능합니다.

Forward Error Correction (FEC)

dm-verity FEC는 Reed-Solomon 부호를 사용하여 손상된 블록을 자동 복구합니다. drivers/md/dm-verity-fec.c에 구현되어 있으며, Android에서는 시스템 파티션에 약 0.8%의 FEC 데이터를 추가하여 비트 에러로 인한 검증 실패 시 자동 복구를 시도합니다. FEC는 dm-verity의 선택 기능으로, veritysetup format에 --fec-device와 --fec-roots 옵션을 지정하여 활성화합니다.

/* drivers/md/dm-verity-fec.h */
struct dm_verity_fec {
    struct dm_dev *dev;           /* FEC 데이터 디바이스 */
    sector_t start;               /* FEC 데이터 시작 섹터 */
    sector_t blocks;              /* FEC 블록 수 */
    sector_t rounds;              /* RS 인코딩 라운드 수 */
    unsigned int rsn;             /* RS 블록 크기 (255 기본) */
    unsigned int roots;            /* RS 패리티 바이트 수 (2 기본) */
    struct dm_bufio_client *bufio;
    mempool_t rs_pool;            /* RS 컨텍스트 풀 */
};

# FEC가 포함된 dm-verity 설정
$ veritysetup format --fec-device=/dev/sda3 --fec-roots=2 \
    /dev/sda1 /dev/sda2

$ veritysetup open --fec-device=/dev/sda3 --fec-roots=2 \
    /dev/sda1 verified_root /dev/sda2 ROOT_HASH

FEC 디코딩 과정을 상세히 살펴보면, dm-verity가 검증 실패를 감지하면 verity_fec_decode()를 호출합니다. 이 함수는 손상된 블록이 포함된 RS 블록을 찾아 decode_rs8()으로 디코딩을 시도합니다. RS(255,253)에서는 최대 1바이트의 에러를 정정할 수 있으며, erasure 위치를 알면 최대 2바이트까지 복구 가능합니다. FEC 복구 성공 시 정정된 데이터가 반환되고, 실패 시 원래의 검증 실패 오류가 전달됩니다.

dm-integrity 개요

dm-integrity는 읽기/쓰기 모두 지원하는 블록 레벨 무결성 보호를 제공합니다. dm-verity와 달리 쓰기 시에도 무결성 태그를 자동으로 계산하여 저장하며, 저널링을 통해 crash-safety를 보장합니다. 커널 소스 drivers/md/dm-integrity.c에 구현되어 있으며, Journal, Bitmap, Direct(no-journal) 세 가지 모드를 제공합니다.

/* drivers/md/dm-integrity.c */
struct dm_integrity_c {
    struct dm_dev *dev;
    struct dm_dev *meta_dev;       /* 별도 메타 디바이스 (선택) */
    unsigned int tag_size;          /* 태그 크기 (바이트) */
    unsigned int sectors_per_block; /* 블록당 섹터 수 */
    __u64 provided_data_sectors;    /* 사용 가능 데이터 섹터 */
    unsigned int journal_entries;
    unsigned int journal_sections;
    struct journal_entry *journal;
    struct crypto_shash *internal_hash;
    struct crypto_shash *journal_mac;
    enum integrity_mode mode;  /* J, B, D (journal/bitmap/direct) */
    bool recalculate;
};

저널링 메커니즘

dm-integrity의 저널은 데이터와 무결성 태그를 원자적(Atomic)으로 기록하여 crash-safety를 보장합니다. 저널은 순환 버퍼(circular buffer)로 구현되며, commit 단위로 데이터+태그 쌍을 기록합니다. Bitmap 모드에서는 저널 대신 비트맵으로 dirty 블록을 추적하며, crash 후 복구 시 dirty 비트가 설정된 블록만 재검증합니다.

/* drivers/md/dm-integrity.c - 저널 엔트리 구조 */
struct journal_entry {
    union {
        struct {
            __le64 sector;       /* 대상 섹터 번호 */
            __le32 data_csum;    /* 데이터 체크섬 */
            __le32 tag_csum;     /* 태그 체크섬 */
        } s;
        __le64 commit_id;         /* 커밋 ID */
    } u;
};

dm-integrity 설정

dm-integrity는 integritysetup 도구로 설정합니다. cryptsetup 패키지에 포함되어 있으며, 포맷 후 활성화하는 2단계로 진행합니다.

# 1. dm-integrity 포맷 (SHA-256 해시, 저널 모드)
$ integritysetup format /dev/sdb1 \
    --integrity sha256 \
    --tag-size 32 \
    --sector-size 4096 \
    --journal-size 64M

# 2. dm-integrity 디바이스 활성화
$ integritysetup open /dev/sdb1 integrity_disk \
    --integrity sha256

# 3. 파일시스템 생성 및 마운트
$ mkfs.ext4 /dev/mapper/integrity_disk
$ mount /dev/mapper/integrity_disk /mnt/secure

# 4. Bitmap 모드로 설정 (성능 우선)
$ integritysetup format /dev/sdb1 \
    --integrity sha256 \
    --integrity-bitmap-mode \
    --bitmap-sectors-per-bit 65536

$ integritysetup open /dev/sdb1 integrity_bitmap \
    --integrity sha256 \
    --integrity-bitmap-mode

dm-integrity 커널 내부 구현

dm-integrity의 커널 구현은 drivers/md/dm-integrity.c에 있으며, 약 4,500줄에 달하는 복잡한 코드입니다. 핵심 동작은 bio를 분할하여 데이터와 무결성 태그를 동시에 처리하는 것입니다.

/* drivers/md/dm-integrity.c - map 함수 */
static int integrity_map(struct dm_target *ti, struct bio *bio)
{
    struct dm_integrity_c *ic = ti->private;
    struct dm_integrity_io *dio;

    dio = dm_per_bio_data(bio, ti->per_io_data_size);
    dio->ic = ic;
    dio->bi_sector = bio->bi_iter.bi_sector;
    dio->bi_integrity = bio_integrity(bio);

    if (bio_data_dir(bio) == WRITE) {
        if (ic->mode == 'J') {
            /* Journal 모드: 저널에 먼저 기록 */
            integrity_journal_write(ic, dio);
        } else if (ic->mode == 'B') {
            /* Bitmap 모드: dirty 비트 설정 */
            integrity_bitmap_write(ic, dio);
        }
        /* 무결성 태그 계산 및 저장 */
        integrity_metadata_write(ic, dio);
    } else {
        /* READ: 데이터 읽기 후 태그 검증 */
        integrity_metadata_read(ic, dio);
    }

    /* bio를 데이터 디바이스로 remap */
    bio_set_dev(bio, ic->dev->bdev);
    bio->bi_iter.bi_sector = integrity_data_sector(ic, dio->bi_sector);

    return DM_MAPIO_REMAPPED;
}

/* 무결성 태그 검증 (읽기 시) */
static int integrity_check_tag(struct dm_integrity_c *ic,
                               u8 *data, u8 *stored_tag,
                               sector_t sector)
{
    u8 computed_tag[MAX_TAG_SIZE];
    int r;

    /* 해시 계산 */
    r = crypto_shash_digest(ic->internal_hash_desc,
                            data, ic->sectors_per_block << SECTOR_SHIFT,
                            computed_tag);
    if (r)
        return r;

    /* 저장된 태그와 비교 */
    if (memcmp(computed_tag, stored_tag, ic->tag_size)) {
        DMERR("integrity checksum failed at sector %llu",
              (unsigned long long)sector);
        return -EILSEQ;
    }
    return 0;
}

dm-integrity의 I/O 경로에서 주의할 점은 메타데이터 I/O입니다. 데이터와 태그가 디스크 상에서 인터리빙되어 있기 때문에, 연속적인 데이터 I/O가 비연속적인 디스크 I/O로 변환될 수 있습니다. 이로 인해 HDD에서는 성능 저하가 심각할 수 있으며, SSD에서는 상대적으로 영향이 적습니다. 별도의 메타 디바이스(--data-device)를 사용하면 이 문제를 완화할 수 있습니다.

dm-integrity의 내부 동작을 더 깊이 살펴보면, 데이터 섹터와 태그 영역의 매핑이 핵심입니다. 논리 섹터 번호를 물리 섹터 번호로 변환할 때, 태그 영역의 크기를 고려하여 오프셋(Offset)을 계산합니다. 이 변환은 get_data_sector() 함수에서 수행됩니다.

/* drivers/md/dm-integrity.c - 섹터 변환 */
static sector_t get_data_sector(struct dm_integrity_c *ic,
                                 area_t area, sector_t offset)
{
    sector_t result;

    /* 데이터 영역과 태그 영역이 인터리빙됨
     * area = 논리 섹터 / interleave_sectors
     * offset = 논리 섹터 % interleave_sectors */
    result = area * (ic->interleave_sectors + ic->tag_area_sectors);
    result += ic->initial_sectors;  /* 슈퍼블록 + 저널 공간 */
    result += offset;

    return result;
}

/* 태그 읽기/쓰기 - 메타데이터 I/O */
static void rw_tag(struct dm_integrity_c *ic,
                   unsigned int tag_offset,
                   u8 *tag, unsigned int tag_size,
                   int op)
{
    sector_t tag_sector;
    unsigned int tag_sector_offset;

    /* 태그의 디스크 위치 계산 */
    tag_sector = tag_offset / (ic->tag_size * ic->journal_section_entries);
    tag_sector_offset = tag_offset % (ic->tag_size * ic->journal_section_entries);

    if (op == TAG_READ)
        dm_bufio_read(ic->tag_bufio, tag_sector, ...);
    else
        dm_bufio_write_dirty(ic->tag_bufio, tag_sector, ...);
}

# 별도 메타 디바이스로 dm-integrity 설정 (성능 최적화)
$ integritysetup format --data-device /dev/nvme0n1p1 /dev/nvme1n1p1     --integrity sha256 --sector-size 4096

# 결과: 데이터는 nvme0n1p1, 태그는 nvme1n1p1에 저장
# 두 NVMe를 병렬로 사용하여 성능 극대화

dm-crypt 개요

dm-crypt는 블록 레벨 투명 암호화를 제공하는 Device Mapper target입니다. drivers/md/dm-crypt.c에 구현되어 있으며, LUKS(Linux Unified Key Setup) 포맷과 함께 리눅스의 표준 디스크 암호화 솔루션으로 사용됩니다. 모든 읽기/쓰기 I/O가 dm-crypt를 통과하면서 투명하게 암/복호화(Decryption)됩니다.

LUKS2(Linux Unified Key Setup version 2)는 dm-crypt의 표준 온디스크 포맷입니다. LUKS1과 비교하여 JSON 메타데이터, Argon2id PBKDF, 최대 32개 키 슬롯, 큰 헤더 크기(최대 64MB), 인증 암호화(AEAD) 지원 등이 추가되었습니다.

/* LUKS2 온디스크 헤더 구조 (간략화) */
struct luks2_hdr_disk {
    char magic[6];          /* "LUKSº¾" */
    uint16_t version;        /* 2 */
    uint64_t hdr_size;       /* 전체 헤더 크기 */
    uint64_t seqid;          /* 시퀀스 ID (원자적 업데이트) */
    char label[48];          /* 볼륨 라벨 */
    char checksum_alg[32];   /* "sha256" */
    uint8_t salt[64];        /* 헤더 salt */
    char uuid[40];           /* UUID */
    char subsystem[48];      /* 서브시스템 */
    uint64_t hdr_offset;     /* JSON 영역 시작 */
    char _padding[184];
    uint8_t csum[64];        /* 헤더 체크섬 */
    /* 이후: JSON 메타데이터 영역 */
    /* 이후: 키 슬롯 바이너리 영역 */
};

/* LUKS2 JSON 메타데이터 예시 (cryptsetup luksDump) */
/*
{
  "keyslots": {
    "0": {
      "type": "luks2",
      "key_size": 64,
      "af": { "type": "luks1", "stripes": 4000, "hash": "sha256" },
      "kdf": {
        "type": "argon2id",
        "time": 4,
        "memory": 1048576,
        "cpus": 4,
        "salt": "base64..."
      },
      "area": {
        "type": "raw",
        "offset": "32768",
        "size": "258048",
        "encryption": "aes-xts-plain64",
        "key_size": 64
      }
    }
  },
  "segments": {
    "0": {
      "type": "crypt",
      "offset": "16777216",
      "size": "dynamic",
      "iv_tweak": "0",
      "encryption": "aes-xts-plain64",
      "sector_size": 512
    }
  }
}
*/

/* drivers/md/dm-crypt.c */
struct crypt_config {
    struct dm_dev *dev;
    sector_t start;                /* 암호화 시작 섹터 */

    struct crypto_skcipher **tfms;  /* 대칭키 암호 핸들 (CPU별) */
    unsigned int tfms_count;       /* CPU 수만큼 할당 */
    char *cipher_string;           /* "aes-xts-plain64" 등 */

    /* IV 생성 */
    const struct crypt_iv_operations *iv_gen_ops;
    char *iv_mode;                 /* "plain64", "essiv" 등 */
    unsigned int iv_size;

    /* 키 관리 */
    u8 *key;
    unsigned int key_size;
    unsigned int key_parts;
    struct key *key_desc;          /* keyring 키 */

    /* 워크큐 */
    struct workqueue_struct *io_queue;
    struct workqueue_struct *crypt_queue;
    mempool_t page_pool;
    unsigned int num_write_bios;
};

# LUKS2 볼륨 생성 (AES-256-XTS)
$ cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 \
    --key-size 512 \
    --hash sha256 \
    --pbkdf argon2id \
    /dev/sdb1

# LUKS 볼륨 열기
$ cryptsetup open /dev/sdb1 encrypted_disk

# plain dm-crypt (LUKS 없이)
$ echo "0 $(blockdev --getsz /dev/sdb1) crypt aes-xts-plain64 \
    $(xxd -l 64 -p /dev/urandom | tr -d '\n') \
    0 /dev/sdb1 0" | dmsetup create plain_crypt

암호화 알고리즘

dm-crypt는 커널 Crypto API를 통해 다양한 암호화 알고리즘을 지원합니다. 알고리즘 문자열은 cipher-chainmode-ivmode 형식으로 지정합니다.

/* drivers/md/dm-crypt.c - IV 생성 운영 구조체 */
static const struct crypt_iv_operations crypt_iv_plain64_ops = {
    .generator = crypt_iv_plain64_gen,
};

static int crypt_iv_plain64_gen(struct crypt_config *cc,
                                u8 *iv,
                                struct dm_crypt_request *dmreq)
{
    /* IV = 섹터 번호 (64비트 리틀 엔디언) */
    memset(iv, 0, cc->iv_size);
    *(__le64 *)iv = cpu_to_le64(dmreq->iv_sector);
    return 0;
}

/* Adiantum: ChaCha + AES로 구성된 와이드 블록 암호 */
/* AES-NI가 없는 ARMv7/저사양 환경에서 AES-XTS보다 5배 빠름 */
/* Google이 Android Go 디바이스용으로 커널 5.0에 추가 */

IV 생성 모드 상세 비교

dm-crypt의 IV(Initialization Vector) 생성 모드는 동일한 평문 블록이 동일한 암호문으로 변환되는 것을 방지합니다. 각 섹터마다 고유한 IV를 생성하여 ECB 모드의 취약점(Vulnerability)을 회피합니다. 주요 IV 생성 모드를 상세히 비교합니다.

/* ESSIV (Encrypted Salt-Sector Initialization Vector) */
/* Watermark 공격: 공격자가 섹터 번호를 알면 plain64에서
 * 동일 평문의 섹터를 식별할 수 있음
 * ESSIV는 섹터 번호를 AES(hash(key))로 암호화하여 방어 */

static int crypt_iv_essiv_gen(struct crypt_config *cc,
                               u8 *iv,
                               struct dm_crypt_request *dmreq)
{
    /* IV = AES_ECB(SHA256(master_key), sector_number) */
    memset(iv, 0, cc->iv_size);
    *(__le64 *)iv = cpu_to_le64(dmreq->iv_sector);

    /* ESSIV 전용 cipher로 섹터 번호 암호화 */
    crypto_cipher_encrypt_one(cc->iv_gen_private.essiv.tfm,
                              iv, iv);
    return 0;
}

/* XTS 모드에서는 ESSIV가 불필요 (내장 tweak 메커니즘)
 * AES-XTS: T = AES(key2, sector_number) * alpha^j
 * 각 16바이트 블록마다 고유한 tweak 값 적용 */

인라인 암호화 엔진 (ICE) 연동

최신 모바일 SoC(Qualcomm, Samsung, MediaTek)에는 Inline Crypto Engine(ICE)이 내장되어 있어, dm-crypt 없이도 하드웨어 레벨에서 블록 암호화를 수행합니다. Linux 커널은 blk-crypto 프레임워크(block/blk-crypto.c)를 통해 ICE를 활용하며, dm-crypt와 투명하게 대체됩니다.

/* block/blk-crypto.c - 인라인 암호화 프레임워크 */
struct blk_crypto_key {
    struct blk_crypto_config crypto_cfg;
    unsigned int data_unit_size;
    unsigned int size;
    u8 raw[BLK_CRYPTO_MAX_KEY_SIZE];
};

/* bio에 암호화 컨텍스트 연결 */
void bio_crypt_set_ctx(struct bio *bio,
                       const struct blk_crypto_key *key,
                       u64 dun_lo, gfp_t gfp_mask)
{
    struct bio_crypt_ctx *bc;
    bc = mempool_alloc(bio_crypt_ctx_pool, gfp_mask);
    bc->bc_key = key;
    bc->bc_dun[0] = dun_lo;
    bio->bi_crypt_context = bc;
}

/* 하드웨어가 blk-crypto를 지원하지 않으면
 * blk-crypto-fallback이 소프트웨어로 처리 (= dm-crypt과 유사) */

dm-crypt 성능

dm-crypt의 성능은 암호화 연산의 병렬화, 하드웨어 가속, 워크큐 설정에 크게 의존합니다. 커널 5.x 이후 submit_from_crypt_cpus, no_read_workqueue, no_write_workqueue 플래그가 추가되어 성능 최적화가 가능합니다.

# 성능 최적화된 dm-crypt 설정
$ cryptsetup open --type luks2 /dev/nvme0n1p2 encrypted \
    --perf-no_read_workqueue \
    --perf-no_write_workqueue \
    --perf-submit_from_crypt_cpus

# 런타임에 플래그 변경
$ dmsetup table encrypted --showkeys | \
    sed 's/$/ 3 no_read_workqueue no_write_workqueue submit_from_crypt_cpus/' | \
    dmsetup reload encrypted
$ dmsetup resume encrypted

# fio 벤치마크: 암호화 오버헤드 측정
$ fio --name=randread --ioengine=io_uring --iodepth=64 \
    --rw=randread --bs=4k --direct=1 --numjobs=4 \
    --filename=/dev/mapper/encrypted --runtime=30 \
    --group_reporting

/* drivers/md/dm-crypt.c - crypt_map() 핵심 */
static int crypt_map(struct dm_target *ti, struct bio *bio)
{
    struct crypt_config *cc = ti->private;
    struct dm_crypt_io *io;

    /* FLUSH/PREFLUSH 바이패스 */
    if (unlikely(bio->bi_opf & REQ_PREFLUSH)) {
        bio_set_dev(bio, cc->dev->bdev);
        return DM_MAPIO_REMAPPED;
    }

    io = dm_per_bio_data(bio, cc->per_bio_data_size);
    crypt_io_init(io, cc, bio, bio->bi_iter.bi_sector);

    if (bio_data_dir(bio) == READ) {
        if (cc->on_disk_tag_size) {
            /* AEAD 모드: 태그도 함께 읽기 */
            io->ctx.bio_in = bio;
            io->ctx.iter_in = bio->bi_iter;
        }
        crypt_read(io);
    } else {
        crypt_write(io);
    }

    return DM_MAPIO_SUBMITTED;
}

/* 암호화 변환 - CPU별 tfm 사용으로 락 경합 방지 */
static int crypt_convert(struct crypt_config *cc,
                         struct convert_context *ctx,
                         bool aead_recheck,
                         bool reset_pending)
{
    unsigned int tag_offset = 0;
    sector_t sector = ctx->cc_sector;
    int r;

    /* CPU별 암호 핸들 선택 (lock-free) */
    struct crypto_skcipher *tfm =
        cc->tfms[smp_processor_id() % cc->tfms_count];

    while (ctx->iter_in.bi_size) {
        /* IV 생성 */
        cc->iv_gen_ops->generator(cc, org_iv, &dmreq->iv_sector);

        /* skcipher 비동기 요청 */
        skcipher_request_set_crypt(req, &sg_in, &sg_out,
                                   cc->sector_size, org_iv);

        if (bio_data_dir(ctx->bio_in) == WRITE)
            r = crypto_skcipher_encrypt(req);
        else
            r = crypto_skcipher_decrypt(req);

        sector++;
    }
    return 0;
}

dm-crypt + dm-integrity 결합

dm-crypt와 dm-integrity를 결합하면 인증 암호화(AEAD)를 구현할 수 있습니다. AES-GCM 또는 ChaCha20-Poly1305 같은 AEAD 알고리즘을 사용하여 암호화와 무결성 검증을 단일 연산으로 수행합니다. 이 결합 모드에서 dm-crypt는 암호화 담당, dm-integrity는 인증 태그 저장 담당입니다.

# AEAD 모드 LUKS2 볼륨 생성 (AES-GCM)
$ cryptsetup luksFormat --type luks2 \
    --cipher aes-gcm-random \
    --integrity aead \
    --sector-size 4096 \
    --key-size 256 \
    /dev/sdb1

# HMAC 무결성 (비 AEAD, 별도 해시)
$ cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 \
    --integrity hmac-sha256 \
    --sector-size 4096 \
    --key-size 512 \
    /dev/sdb1

# dm-integrity 디바이스가 자동 생성됨
$ dmsetup ls
encrypted        (254:1)
encrypted_dif    (254:0)  # dm-integrity 레이어

# 상태 확인
$ cryptsetup status encrypted
  type:    LUKS2
  cipher:  aes-gcm-random
  keysize: 256 bits
  integrity: aead
  integrity keysize: 0 bits  # AEAD는 별도 키 불필요

dm-flakey / dm-dust

dm-flakey와 dm-dust는 테스트 및 결함 주입(fault injection)용 Device Mapper target입니다. 파일시스템이나 스토리지 스택의 에러 처리 경로를 테스트하는 데 사용됩니다.

/* dm-flakey: 주기적으로 I/O 에러를 발생시킴 */
# 10초 정상 동작 후 5초간 모든 I/O에 에러 반환
$ echo "0 $(blockdev --getsz /dev/sdb1) flakey /dev/sdb1 0 10 5" | \
    dmsetup create flakey_disk

# 옵션: 쓰기만 실패, 읽기는 정상
$ echo "0 $(blockdev --getsz /dev/sdb1) flakey /dev/sdb1 0 10 5 \
    1 drop_writes" | dmsetup create flakey_write

# dm-flakey 커널 구현 (간략화)
static int flakey_map(struct dm_target *ti, struct bio *bio)
{
    struct flakey_c *fc = ti->private;
    unsigned elapsed = jiffies - fc->start_time;

    if (elapsed % (fc->up_interval + fc->down_interval)
        >= fc->up_interval) {
        /* down 구간: 에러 반환 또는 데이터 변조 */
        if (fc->drop_writes && bio_data_dir(bio) == WRITE) {
            bio_endio(bio);  /* 쓰기 무시 */
            return DM_MAPIO_SUBMITTED;
        }
        bio->bi_status = BLK_STS_IOERR;
        bio_endio(bio);
        return DM_MAPIO_SUBMITTED;
    }

    /* up 구간: 정상 통과 */
    flakey_map_bio(ti, bio);
    return DM_MAPIO_REMAPPED;
}

/* dm-dust: 특정 블록에 읽기 에러를 주입 */
# dm-dust 디바이스 생성
$ echo "0 $(blockdev --getsz /dev/sdb1) dust /dev/sdb1 0 4096" | \
    dmsetup create dusty_disk

# 특정 블록에 bad block 마킹
$ dmsetup message dusty_disk 0 addbadblock 100
$ dmsetup message dusty_disk 0 addbadblock 200

# bad block 활성화
$ dmsetup message dusty_disk 0 enable

# 블록 100, 200 읽기 시 -EIO 반환
# 파일시스템의 에러 핸들링 로직 테스트에 활용

# bad block 제거
$ dmsetup message dusty_disk 0 removebadblock 100

dm-user / dm-verity-loadpin

dm-user는 사용자 공간에서 Device Mapper target을 구현할 수 있게 하는 메커니즘입니다. ChromeOS와 Android에서 보안 부팅 체인을 강화하는 데 사용됩니다. dm-verity-loadpin은 커널 모듈(Kernel Module)과 펌웨어(Firmware) 로딩을 dm-verity로 검증된 파티션으로 제한합니다.

/* security/loadpin/loadpin.c */
/* LoadPin: 모든 커널 모듈/펌웨어가
 * 동일한 검증된 파일시스템에서만 로드되도록 강제 */

static int loadpin_read_file(struct file *file,
                            enum kernel_read_file_id id,
                            bool contents)
{
    struct super_block *load_root = READ_ONCE(pinned_root);

    if (!load_root) {
        /* 첫 번째 로드: 이 파일시스템을 "pin" */
        pinned_root = file->f_path.mnt->mnt_sb;
        return 0;
    }

    /* 이후 모든 로드는 pinned root와 동일한 fs에서만 허용 */
    if (file->f_path.mnt->mnt_sb != load_root) {
        pr_info("LoadPin: denied loading from different fs\n");
        return -EPERM;
    }
    return 0;
}

/* dm-verity + LoadPin = 검증된 파티션에서만 커널 모듈 로드 */

# ChromeOS dm-verity + LoadPin 부팅 체인
# 1. 부트로더가 커널 서명 검증
# 2. 커널이 rootfs에 dm-verity 활성화
# 3. LoadPin이 첫 번째 모듈 로드 경로를 기록
# 4. 이후 모든 모듈/펌웨어는 동일 경로에서만 로드 허용

# Android: dm-verity + dm-user (snapuserd)
# snapuserd는 Virtual A/B OTA 업데이트에서
# copy-on-write 스냅샷을 사용자 공간에서 처리
$ ps aux | grep snapuserd
root  1234  0.5  0.2  snapuserd /dev/dm-user/system_cow

Device Mapper 타겟 개발

커스텀 Device Mapper target을 개발하려면 struct target_type을 구현하고 dm_register_target()으로 등록합니다. 최소한 ctr(생성자), dtr(소멸자), map(I/O 매핑) 콜백이 필요합니다.

/* 예제: 최소 dm target 구현 */
#include <linux/device-mapper.h>

struct my_target_data {
    struct dm_dev *dev;
    sector_t start;
    atomic64_t io_count;
};

/* 생성자: dmsetup create 시 호출 */
static int my_ctr(struct dm_target *ti,
                  unsigned int argc, char **argv)
{
    struct my_target_data *mtd;
    int r;

    if (argc != 2) {
        ti->error = "requires 2 arguments: dev_path offset";
        return -EINVAL;
    }

    mtd = kzalloc(sizeof(*mtd), GFP_KERNEL);
    if (!mtd)
        return -ENOMEM;

    r = dm_get_device(ti, argv[0], dm_table_get_mode(ti->table),
                      &mtd->dev);
    if (r) {
        kfree(mtd);
        return r;
    }

    if (kstrtoull(argv[1], 10, &mtd->start)) {
        dm_put_device(ti, mtd->dev);
        kfree(mtd);
        return -EINVAL;
    }

    atomic64_set(&mtd->io_count, 0);
    ti->private = mtd;
    return 0;
}

/* 소멸자 */
static void my_dtr(struct dm_target *ti)
{
    struct my_target_data *mtd = ti->private;
    dm_put_device(ti, mtd->dev);
    kfree(mtd);
}

/* I/O 매핑: 모든 bio에 대해 호출 */
static int my_map(struct dm_target *ti, struct bio *bio)
{
    struct my_target_data *mtd = ti->private;

    atomic64_inc(&mtd->io_count);
    bio_set_dev(bio, mtd->dev->bdev);
    bio->bi_iter.bi_sector = mtd->start +
        dm_target_offset(ti, bio->bi_iter.bi_sector);

    return DM_MAPIO_REMAPPED;
}

/* 상태 보고 */
static void my_status(struct dm_target *ti,
                      status_type_t type,
                      unsigned int status_flags,
                      char *result, unsigned int maxlen)
{
    struct my_target_data *mtd = ti->private;

    switch (type) {
    case STATUSTYPE_INFO:
        snprintf(result, maxlen, "io_count=%lld",
                 atomic64_read(&mtd->io_count));
        break;
    case STATUSTYPE_TABLE:
        snprintf(result, maxlen, "%s %llu",
                 mtd->dev->name, mtd->start);
        break;
    }
}

static struct target_type my_target = {
    .name    = "my_target",
    .version = {1, 0, 0},
    .module  = THIS_MODULE,
    .ctr     = my_ctr,
    .dtr     = my_dtr,
    .map     = my_map,
    .status  = my_status,
};

static int __init my_init(void)
{
    return dm_register_target(&my_target);
}

static void __exit my_exit(void)
{
    dm_unregister_target(&my_target);
}

module_init(my_init);
module_exit(my_exit);
MODULE_LICENSE("GPL");

/* Makefile for out-of-tree DM target module */
obj-m := dm-mytarget.o

KDIR := /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

# 빌드 및 로드
$ make
$ sudo insmod dm-mytarget.ko
$ sudo dmsetup create mydev --table "0 2097152 my_target /dev/sdb1 0"

# 상태 확인
$ sudo dmsetup status mydev
0 2097152 my_target io_count=42

# 제거
$ sudo dmsetup remove mydev
$ sudo rmmod dm-mytarget

고급 target 개발 시 고려해야 할 사항들입니다:

성능 최적화

Device Mapper target들의 성능을 최적화하려면 I/O 스케줄링, prefetch, 병렬 처리, 메모리 할당 전략을 종합적으로 고려해야 합니다. 특히 dm-verity와 dm-crypt는 각각 해시 계산과 암호화 연산이 병목(Bottleneck)이 되므로, 하드웨어 가속과 병렬화가 핵심입니다.

# dm-verity prefetch 및 캐시 최적화
# check_at_most_once: 각 블록을 최대 1회만 검증 (메모리 사용 증가)
$ echo "0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 \
    262144 1 sha256 ROOT_HASH SALT \
    2 check_at_most_once use_fec_from_device /dev/sda3" | \
    dmsetup create verified_opt

# dm-crypt I/O 스케줄러 최적화
$ echo none > /sys/block/dm-0/queue/scheduler
$ echo 256 > /sys/block/dm-0/queue/read_ahead_kb

# dm-integrity bitmap 모드 (성능 우선)
$ integritysetup format /dev/sdb1 \
    --integrity sha256 \
    --integrity-bitmap-mode \
    --bitmap-sectors-per-bit 65536 \
    --bitmap-flush-time 5000

# 암호화 성능 벤치마크
$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
# Algorithm |       Key |      Encryption |      Decryption
    aes-xts        256b      4512.5 MiB/s      4487.3 MiB/s
    aes-xts        512b      3891.2 MiB/s      3867.8 MiB/s
   serpent-xts     256b       618.3 MiB/s       612.7 MiB/s
   twofish-xts     256b       504.1 MiB/s       510.3 MiB/s
    aes-cbc        256b      1356.8 MiB/s      4231.4 MiB/s

보안 고려사항

dm-crypt/dm-verity/dm-integrity의 보안은 키 관리, 알고리즘 선택, 부팅 체인 무결성에 의존합니다. 커널의 keyring 서브시스템, TPM, FIPS 모드를 활용하여 보안을 강화할 수 있습니다.

# TPM 2.0 Sealed Key로 LUKS 잠금 해제
$ systemd-cryptenroll --tpm2-device=auto /dev/sdb1
$ cryptsetup open --token-only /dev/sdb1 encrypted

# FIDO2 하드웨어 토큰 등록
$ systemd-cryptenroll --fido2-device=auto /dev/sdb1

# 커널 keyring 연동
$ keyctl add logon dmcrypt:my_key 32 @s < /path/to/key
$ echo "0 $(blockdev --getsz /dev/sdb1) crypt aes-xts-plain64 \
    :64:logon:dmcrypt:my_key 0 /dev/sdb1 0" | dmsetup create enc

# FIPS 모드 확인
$ cat /proc/sys/crypto/fips_enabled
1
# FIPS 모드에서는 승인된 알고리즘만 사용 가능
# AES-XTS, AES-CBC, SHA-256, HMAC-SHA256 등

# TPM2 PCR 정책으로 LUKS 키 봉인
# PCR7 = Secure Boot 상태, PCR4 = 부트 관리자
$ systemd-cryptenroll --tpm2-device=auto     --tpm2-pcrs=4+7     /dev/sdb1

# TPM 봉인 키 상태 확인
$ systemd-cryptenroll /dev/sdb1
SLOT TYPE
0    password
1    tpm2 (pcrs: 4+7, device: /dev/tpmrm0)

# FIDO2 YubiKey로 잠금 해제
$ systemd-cryptenroll --fido2-device=auto     --fido2-with-client-pin=yes     --fido2-with-user-presence=yes     /dev/sdb1

# 복구 키 생성 (비상 잠금 해제용)
$ systemd-cryptenroll --recovery-key /dev/sdb1
# 출력: mmmm-mmmm-mmmm-mmmm-mmmm-mmmm-mmmm-mmmm (base58 복구 키)

luksSuspend와 luksResume을 활용한 키 보호 전략도 중요합니다. 시스템이 절전 모드(suspend to RAM)에 진입할 때 luksSuspend로 dm-crypt의 마스터 키를 커널 메모리에서 삭제하면, Cold Boot 공격으로부터 키를 보호할 수 있습니다. 복귀 시 luksResume으로 비밀번호를 재입력받아 키를 복원합니다.

# 절전 전 키 삭제
$ cryptsetup luksSuspend encrypted

# 복귀 후 키 복원
$ cryptsetup luksResume encrypted

# systemd suspend hook 설정
# /etc/systemd/system/cryptsetup-suspend@.service
[Unit]
Description=Suspend dm-crypt device
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cryptsetup luksSuspend %i
ExecStartPost=/usr/bin/systemctl suspend

[Install]
WantedBy=sleep.target

/* 커널 dm-verity 루트 해시 서명 검증 */
/* CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG=y 필요 */

/* 서명 검증 흐름:
 * 1. verity_ctr()에서 root_hash_sig_key_desc 옵션 파싱
 * 2. 커널 keyring에서 서명 키 조회 (.builtin_trusted_keys)
 * 3. PKCS#7 서명 검증 (verify_pkcs7_signature())
 * 4. 서명이 유효하면 dm-verity 활성화 허용 */

static int verity_verify_root_hash(struct dm_verity *v,
                                    const void *root_hash,
                                    size_t root_hash_len,
                                    const void *sig,
                                    size_t sig_len)
{
    struct key *key;
    int r;

    /* .dm_verity_keys 또는 .builtin_trusted_keys 키링 검색 */
    key = keyring_search(
        make_key_ref(VERIFY_USE_SECONDARY_KEYRING, 1),
        &key_type_asymmetric, v->root_hash_sig_key_desc);

    r = verify_pkcs7_signature(root_hash, root_hash_len,
                               sig, sig_len,
                               VERIFY_USE_SECONDARY_KEYRING,
                               VERIFYING_MODULE_SIGNATURE,
                               NULL, NULL);
    return r;
}

실전 활용

dm-verity, dm-integrity, dm-crypt는 서버 디스크 암호화, 임베디드 검증 부팅, 컨테이너 이미지 보호, CI/CD 파이프라인(Pipeline) 등 다양한 실전 시나리오에서 활용됩니다.

## 시나리오 1: 서버 전체 디스크 암호화 (Clevis + Tang)

# 1. LUKS2 포맷
$ cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 --key-size 512 \
    --pbkdf argon2id /dev/nvme0n1p3

# 2. Tang 서버 바인딩 (네트워크 기반 자동 잠금 해제)
$ clevis luks bind -d /dev/nvme0n1p3 tang \
    '{"url":"http://tang.internal:7500"}'

# 3. 부팅 시 자동 잠금 해제 (initramfs)
$ dracut -f --regenerate-all  # clevis dracut 모듈 포함

## 시나리오 2: 임베디드 검증 부팅 이미지 빌드

# 1. 루트 파일시스템 이미지 생성
$ mksquashfs rootfs/ rootfs.img -comp zstd

# 2. dm-verity 해시 트리 생성
$ veritysetup format rootfs.img hash.img > verity_info.txt
$ ROOT_HASH=$(grep "Root hash" verity_info.txt | awk '{print $3}')

# 3. FEC 데이터 생성
$ veritysetup format --fec-device=fec.img --fec-roots=2 \
    rootfs.img hash.img

# 4. 커널 cmdline에 dm-verity 파라미터 추가
$ echo "dm=\"1 vroot none ro 1,0 $(stat -c%s rootfs.img | \
    awk '{print $1/512}') verity 1 PARTUUID=xxx PARTUUID=yyy \
    4096 4096 $(stat -c%s rootfs.img | awk '{print $1/4096}') \
    1 sha256 $ROOT_HASH -\"" >> cmdline.txt

## 시나리오 3: 컨테이너 이미지 + dm-verity

# composefs / ostree + dm-verity
$ mkcomposefs --digest-store=objects/ rootfs/ image.cfs
# composefs는 erofs + dm-verity를 사용하여
# 컨테이너 이미지의 무결성을 검증

LUKS2 키 관리 운영

# LUKS2 헤더 정보 확인
$ cryptsetup luksDump /dev/sdb1
LUKS header information
Version:        2
Epoch:          5
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           a1b2c3d4-e5f6-7890-abcd-ef1234567890
Label:          encrypted-data
Subsystem:      (no subsystem)
Flags:          (no flags)

Keyslots:
  0: luks2
    Key:        512 bits
    Priority:   normal
    Cipher:     aes-xts-plain64
    Cipher key: 512 bits
    PBKDF:      argon2id
    Time cost:  4
    Memory:     1048576
    Threads:    4

  1: luks2 (tpm2)
    Key:        512 bits
    Priority:   prefer
    Cipher:     aes-xts-plain64

Tokens:
  0: systemd-tpm2
    tpm2-pcrs: 4+7
    tpm2-bank: sha256

Data segments:
  0: crypt
    offset:  16777216 [bytes]
    length:  (whole device)
    cipher:  aes-xts-plain64
    sector:  4096 [bytes]

# 키 슬롯 추가 (새 비밀번호)
$ cryptsetup luksAddKey /dev/sdb1

# 키 슬롯 제거
$ cryptsetup luksKillSlot /dev/sdb1 2

# 온라인 마스터 키 변경 (LUKS2 전용)
$ cryptsetup reencrypt --init-only /dev/sdb1
$ cryptsetup reencrypt --resume-only /dev/sdb1

# 알고리즘 변경 (재암호화)
$ cryptsetup reencrypt /dev/sdb1     --cipher aes-xts-plain64 --key-size 512

# LUKS 볼륨 크기 확장
$ cryptsetup resize encrypted
$ resize2fs /dev/mapper/encrypted

## 시나리오 4: Kubernetes 시크릿 볼륨 암호화

# CSI 드라이버 + dm-crypt으로 PVC 암호화
# 1. StorageClass에 암호화 파라미터 정의
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-ssd
provisioner: csi.example.com
parameters:
  encryption: "true"
  cipher: "aes-xts-plain64"
  keySize: "512"
  pbkdf: "argon2id"

# 2. 노드에서 PVC가 마운트될 때 자동 LUKS 포맷/열기
# CSI NodeStageVolume에서:
# - cryptsetup luksFormat /dev/xvdf
# - cryptsetup open /dev/xvdf pvc-xxx
# - mkfs.ext4 /dev/mapper/pvc-xxx
# - mount /dev/mapper/pvc-xxx /var/lib/kubelet/pods/...

## 시나리오 5: dm-verity + SquashFS 컨테이너 이미지

# 1. 컨테이너 rootfs를 SquashFS 이미지로 압축
$ mksquashfs container_rootfs/ image.squashfs -comp zstd -Xcompression-level 19

# 2. dm-verity 해시 트리 생성
$ veritysetup format image.squashfs hash.img     --hash sha256 --data-block-size 4096
Root hash: abcdef...

# 3. 이미지 서명 (cosign 또는 GPG)
$ cosign sign --key cosign.key docker.io/myapp:latest

# 4. 런타임에 검증된 마운트
$ losetup /dev/loop0 image.squashfs
$ losetup /dev/loop1 hash.img
$ veritysetup open /dev/loop0 verified_container /dev/loop1 abcdef...
$ mount -t squashfs /dev/mapper/verified_container /mnt/container

## 시나리오 6: dm-integrity로 서버 데이터 무결성 보호

# 데이터베이스 서버: HMAC-SHA256 무결성 + AES-XTS 암호화
$ cryptsetup luksFormat --type luks2     --cipher aes-xts-plain64     --integrity hmac-sha256     --key-size 512     --sector-size 4096     /dev/nvme0n1p3

# 성능 최적화 옵션으로 열기
$ cryptsetup open /dev/nvme0n1p3 db_encrypted     --perf-no_read_workqueue     --perf-no_write_workqueue     --perf-submit_from_crypt_cpus

# XFS 파일시스템으로 데이터베이스 볼륨 구성
$ mkfs.xfs -f -s size=4096 /dev/mapper/db_encrypted
$ mount -o noatime,nodiratime /dev/mapper/db_encrypted /var/lib/postgresql

dm-crypt 디버깅(Debugging) 및 모니터링

# dm-crypt I/O 통계 확인
$ dmsetup status encrypted
0 2097152 crypt aes-xts-plain64 in_flight:12 ...

# 블록 레이어 I/O 통계
$ cat /sys/block/dm-0/stat
  28547  0  456752  1230  15823  0  253168  890  0  1420  2120

# dm-crypt 워크큐 모니터링
$ cat /proc/sys/kernel/threads-max
$ ps aux | grep kcryptd
root     123  0.5  0.0  [kcryptd]
root     124  0.5  0.0  [kcryptd_io]

# crypto API 알고리즘 확인
$ cat /proc/crypto | grep -A5 "name.*xts(aes)"
name         : xts(aes)
driver       : xts-aes-aesni
module       : aesni_intel
priority     : 401
refcnt       : 3
type         : skcipher

# AES-NI 활성화 확인
$ grep aes /proc/cpuinfo | head -1
flags : ... aes ...

# perf를 이용한 암호화 성능 프로파일링
$ perf top -p $(pgrep kcryptd) -g
# aesni_xts_encrypt/decrypt 함수가 상위에 표시되면 정상

# blktrace로 dm-crypt I/O 지연 분석
$ blktrace -d /dev/dm-0 -o trace &
$ fio --name=test --filename=/dev/mapper/encrypted --rw=randread     --bs=4k --iodepth=32 --numjobs=1 --runtime=10
$ kill %1
$ blkparse -i trace -o analysis.txt
$ btt -i trace.blktrace.0 -o btt_result

# LUKS 헤더 백업 (필수!)
$ cryptsetup luksHeaderBackup /dev/sdb1     --header-backup-file /backup/sdb1-luks-header.img

# LUKS 헤더 복원
$ cryptsetup luksHeaderRestore /dev/sdb1     --header-backup-file /backup/sdb1-luks-header.img

# dm-verity 에러 로그 확인
$ dmesg | grep -i verity
[  12.345678] device-mapper: verity: sha256 using implementation "sha256-avx2"
[  12.345679] device-mapper: verity: 262144 data blocks verified

# dm-integrity 에러 로그
$ dmesg | grep -i integrity
[  15.678901] device-mapper: integrity: initialized, tag size 32
[  15.678902] device-mapper: integrity: journal sectors 131072

# ftrace로 dm 함수 추적
$ echo 1 > /sys/kernel/debug/tracing/events/block/block_bio_remap/enable
$ echo "dm*" > /sys/kernel/debug/tracing/set_ftrace_filter
$ echo function_graph > /sys/kernel/debug/tracing/current_tracer
$ cat /sys/kernel/debug/tracing/trace_pipe | head -50

커널 설정 (Kconfig) 상세

dm-verity vs fs-verity 비교

커널은 dm-verity 외에도 fs-verity(fs/verity/)를 제공합니다. 두 가지 모두 Merkle Tree 기반 무결성 검증이지만, 동작 레벨이 다릅니다.

# fs-verity로 개별 파일 검증 설정
$ fsverity enable /mnt/ext4/important_binary
$ fsverity measure /mnt/ext4/important_binary
sha256:abcdef1234567890... /mnt/ext4/important_binary

# Android에서 APK 검증에 fs-verity 사용 (Android 11+)
# dm-verity는 system 파티션 전체 검증
# fs-verity는 개별 APK 파일 검증

dm-bufio 캐시 아키텍처

dm-verity와 dm-integrity 모두 해시/태그 블록 읽기에 dm_bufio 캐시를 사용합니다. drivers/md/dm-bufio.c에 구현된 dm-bufio는 블록 단위 캐시로, LRU 정책으로 관리되며, 메모리 압박 시 shrinker를 통해 회수됩니다. dm-verity 성능은 해시 블록의 캐시 적중률에 크게 의존합니다.

/* drivers/md/dm-bufio.c - 캐시 클라이언트 생성 */
struct dm_bufio_client *dm_bufio_client_create(
    struct block_device *bdev,
    unsigned int block_size,
    unsigned int reserved_buffers,
    unsigned int aux_size,
    void (*alloc_callback)(struct dm_buffer *),
    void (*write_callback)(struct dm_buffer *),
    unsigned int flags);

/* 캐시 조회/읽기 */
struct dm_buffer *dm_bufio_read(
    struct dm_bufio_client *c,
    sector_t block,
    void **data);
/* 캐시 히트 시 즉시 반환, 미스 시 디스크에서 읽기 */

/* 비동기 prefetch (dm-verity에서 사용) */
void dm_bufio_prefetch(
    struct dm_bufio_client *c,
    sector_t block,
    unsigned int n_blocks);

/* 메모리 압박 시 캐시 축소 (shrinker) */
static unsigned long dm_bufio_shrink_scan(
    struct shrinker *shrink,
    struct shrink_control *sc)
{
    /* LRU 리스트에서 가장 오래된 버퍼부터 해제 */
    return __scan(c, sc->nr_to_scan, sc->gfp_mask);
}

DM Target 개발 완전 예제

Device Mapper target을 개발하려면 struct target_type의 콜백 함수를 구현하고 커널 모듈로 등록합니다. 이 섹션에서는 dm-linear를 클론한 완전한 모듈 예제를 통해 ctr(생성자), dtr(소멸자), map(I/O 매핑), status(상태 보고), message(런타임 명령) 콜백의 실제 구현 패턴을 상세히 살펴봅니다.

아래는 dm-linear를 클론한 완전한 커널 모듈 예제입니다. I/O 카운터와 message 콜백을 추가하여 런타임 통계 리셋 기능도 포함합니다.

/* dm-mylinear.c — dm-linear 클론 + I/O 카운터 + message 콜백 */
#include <linux/module.h>
#include <linux/device-mapper.h>
#include <linux/bio.h>

#define DM_MSG_PREFIX "mylinear"

struct mylinear_c {
    struct dm_dev *dev;
    sector_t start;
    atomic64_t read_ios;
    atomic64_t write_ios;
};

/* 생성자: dmsetup create 시 호출 */
static int mylinear_ctr(struct dm_target *ti,
                        unsigned int argc, char **argv)
{
    struct mylinear_c *lc;
    unsigned long long tmp;
    int r;

    if (argc != 2) {
        ti->error = "requires exactly 2 arguments: <dev_path> <offset>";
        return -EINVAL;
    }

    lc = kzalloc(sizeof(*lc), GFP_KERNEL);
    if (!lc) {
        ti->error = "cannot allocate private data";
        return -ENOMEM;
    }

    /* 하위 디바이스 획득 */
    r = dm_get_device(ti, argv[0],
                      dm_table_get_mode(ti->table), &lc->dev);
    if (r) {
        ti->error = "device lookup failed";
        kfree(lc);
        return r;
    }

    /* 오프셋 파싱 */
    if (sscanf(argv[1], "%llu", &tmp) != 1 ||
        tmp != (sector_t)tmp) {
        ti->error = "invalid offset";
        dm_put_device(ti, lc->dev);
        kfree(lc);
        return -EINVAL;
    }
    lc->start = tmp;

    atomic64_set(&lc->read_ios, 0);
    atomic64_set(&lc->write_ios, 0);
    ti->private = lc;
    ti->num_flush_bios = 1;
    ti->num_discard_bios = 1;
    ti->num_secure_erase_bios = 1;
    ti->num_write_zeroes_bios = 1;

    return 0;
}

/* 소멸자 */
static void mylinear_dtr(struct dm_target *ti)
{
    struct mylinear_c *lc = ti->private;
    dm_put_device(ti, lc->dev);
    kfree(lc);
}

/* I/O 매핑: 모든 bio에 대해 호출 */
static int mylinear_map(struct dm_target *ti,
                        struct bio *bio)
{
    struct mylinear_c *lc = ti->private;

    /* I/O 통계 수집 */
    if (bio_data_dir(bio) == READ)
        atomic64_inc(&lc->read_ios);
    else
        atomic64_inc(&lc->write_ios);

    /* bio를 하위 디바이스로 remapping */
    bio_set_dev(bio, lc->dev->bdev);
    if (bio_sectors(bio) || op_is_zone_mgmt(bio->bi_opf))
        bio->bi_iter.bi_sector = lc->start +
            dm_target_offset(ti, bio->bi_iter.bi_sector);

    return DM_MAPIO_REMAPPED;
}

/* 상태 보고 */
static void mylinear_status(struct dm_target *ti,
    status_type_t type, unsigned int status_flags,
    char *result, unsigned int maxlen)
{
    struct mylinear_c *lc = ti->private;

    switch (type) {
    case STATUSTYPE_INFO:
        snprintf(result, maxlen,
                 "reads=%lld writes=%lld",
                 atomic64_read(&lc->read_ios),
                 atomic64_read(&lc->write_ios));
        break;
    case STATUSTYPE_TABLE:
        snprintf(result, maxlen, "%s %llu",
                 lc->dev->name, (unsigned long long)lc->start);
        break;
    case STATUSTYPE_IMA:
        *result = '\0';
        break;
    }
}

/* message 콜백: 런타임 명령 */
static int mylinear_message(struct dm_target *ti,
    unsigned int argc, char **argv,
    char *result, unsigned int maxlen)
{
    struct mylinear_c *lc = ti->private;

    if (argc == 1 && !strcasecmp(argv[0], "reset_stats")) {
        atomic64_set(&lc->read_ios, 0);
        atomic64_set(&lc->write_ios, 0);
        DMINFO("statistics reset");
        return 0;
    }
    DMERR("unrecognised message: %s", argv[0]);
    return -EINVAL;
}

/* 하위 디바이스 순회 */
static int mylinear_iterate_devices(struct dm_target *ti,
    iterate_devices_callout_fn fn, void *data)
{
    struct mylinear_c *lc = ti->private;
    return fn(ti, lc->dev, lc->start, ti->len, data);
}

static struct target_type mylinear_target = {
    .name            = "mylinear",
    .version         = {1, 0, 0},
    .features        = DM_TARGET_PASSES_INTEGRITY,
    .module          = THIS_MODULE,
    .ctr             = mylinear_ctr,
    .dtr             = mylinear_dtr,
    .map             = mylinear_map,
    .status          = mylinear_status,
    .message         = mylinear_message,
    .iterate_devices = mylinear_iterate_devices,
};

static int __init dm_mylinear_init(void)
{
    return dm_register_target(&mylinear_target);
}

static void __exit dm_mylinear_exit(void)
{
    dm_unregister_target(&mylinear_target);
}

module_init(dm_mylinear_init);
module_exit(dm_mylinear_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Example");
MODULE_DESCRIPTION("DM mylinear — linear clone with I/O stats");

# Makefile — out-of-tree DM target 빌드
obj-m += dm-mylinear.o

KDIR ?= /lib/modules/$(shell uname -r)/build

all:
	make -C $(KDIR) M=$(PWD) modules

clean:
	make -C $(KDIR) M=$(PWD) clean

# 모듈 로드 및 DM 디바이스 생성
sudo insmod dm-mylinear.ko
dmsetup targets | grep mylinear
# mylinear        v1.0.0

# 루프 디바이스 생성 (테스트용 1GB)
dd if=/dev/zero of=/tmp/test.img bs=1M count=1024
sudo losetup /dev/loop0 /tmp/test.img

# DM 디바이스 생성: 0 <sectors> mylinear <dev> <offset>
# 1GB = 2097152 sectors (512B 단위)
echo "0 2097152 mylinear /dev/loop0 0" | sudo dmsetup create mytest

# 동작 확인
ls -la /dev/mapper/mytest
sudo mkfs.ext4 /dev/mapper/mytest
sudo mount /dev/mapper/mytest /mnt/test
echo "hello dm" | sudo tee /mnt/test/hello.txt

# I/O 통계 확인
sudo dmsetup status mytest
# 0 2097152 mylinear reads=42 writes=15

# 통계 리셋
sudo dmsetup message mytest 0 reset_stats
sudo dmsetup status mytest
# 0 2097152 mylinear reads=0 writes=0

# 정리
sudo umount /mnt/test
sudo dmsetup remove mytest
sudo losetup -d /dev/loop0
sudo rmmod dm-mylinear

# 검증: dmesg에서 모듈 로그 확인
dmesg | grep mylinear
# [  123.456] device-mapper: mylinear: statistics reset

# /proc 확인
cat /proc/devices | grep device-mapper
# 253 device-mapper

# sysfs에서 DM 디바이스 확인
ls /sys/block/dm-0/dm/
# name  suspended  uuid
cat /sys/block/dm-0/dm/name
# mytest

blktrace/btrace 분석

blktrace는 블록 레이어의 I/O 이벤트를 실시간으로 추적하는 도구로, DM 디바이스의 I/O 패턴을 분석하는 데 필수적입니다. dm-verity 환경에서는 해시 트리 읽기와 데이터 블록 읽기가 인터리빙되는 패턴을 관찰할 수 있습니다.

# blktrace 기본 사용법: dm-verity 디바이스 추적
# -d: 대상 디바이스, -o -: stdout 출력
sudo blktrace -d /dev/dm-0 -o - | blkparse -i - -o trace.out

# btrace: blktrace + blkparse 간편 래퍼
sudo btrace /dev/dm-0

# 특정 시간(10초) 동안 추적
sudo blktrace -d /dev/dm-0 -w 10 -o verity_trace
blkparse -i verity_trace -d verity_trace.bin

# DM 하위 디바이스도 동시 추적 (remap 관계 확인)
sudo blktrace -d /dev/dm-0 -d /dev/sda -w 5 -o multi_trace
blkparse -i multi_trace -M -o multi_out.txt

# dm-verity I/O 패턴 분석 예제
# A(remap) 이벤트만 필터링: DM 리매핑 추적
blkparse -i verity_trace -a remap -o remap_only.txt

# 출력 예시 해석:
# 253,0  0  1  0.000000000  1234 A  R  2048 + 8  <- (8,0) 4096
#   │    │  │       │        │   │  │   │     │       │      └ 하위 디바이스 섹터
#   │    │  │       │        │   │  │   │     │       └ 하위 디바이스 (major,minor)
#   │    │  │       │        │   │  │   │     └ 길이 (섹터)
#   │    │  │       │        │   │  │   └ DM 디바이스 섹터
#   │    │  │       │        │   │  └ R=Read, W=Write
#   │    │  │       │        │   └ A=remap
#   │    │  │       │        └ PID
#   │    │  │       └ 타임스탬프
#   └────┘──┘ 디바이스 (major,minor) + CPU

# dm-verity 패턴: 해시 블록 읽기 + 데이터 블록 읽기 반복
# hash_dev 읽기 (상위 Merkle 노드) → data_dev 읽기 (실제 데이터)

# btt: blktrace timing 통계 분석
btt -i verity_trace.bin -l verity_latency.dat
# Q2C: 전체 레이턴시 (요청~완료)
# D2C: 디바이스 레이턴시 (디스패치~완료)
# Q2G: 큐잉 레이턴시

# iowatcher: blktrace 결과를 시각화 SVG로 변환
iowatcher -t verity_trace -o verity_io.svg

FIPS 140-2/3 고려사항

FIPS(Federal Information Processing Standards) 140-2/3은 미국 정부가 요구하는 암호화 모듈 인증 표준입니다. 리눅스 커널이 FIPS 모드로 동작할 때 dm-crypt, dm-integrity, dm-verity가 받는 제약과 설정 방법을 정리합니다.

# 커널 FIPS 모드 확인
cat /proc/sys/crypto/fips_enabled
# 1 = FIPS 모드 활성화

# FIPS 모드 부팅 활성화 (GRUB)
# /etc/default/grub에 추가:
# GRUB_CMDLINE_LINUX="fips=1"
sudo update-grub && sudo reboot

# FIPS self-test 결과 확인
dmesg | grep -i fips
# [    0.123] fips: FIPS 140-3 self-tests passed
# [    0.456] alg: self-tests for aes passed
# [    0.789] alg: self-tests for sha256 passed

# FIPS 모드에서 dm-crypt 설정 (승인 알고리즘만 사용)
# AES-XTS-256: FIPS 승인 ✓
sudo cryptsetup luksFormat --type luks2 \
    --cipher aes-xts-plain64 --key-size 512 \
    --hash sha256 --pbkdf argon2id \
    /dev/sda2

# FIPS 비승인 알고리즘 시도 → 실패
sudo cryptsetup luksFormat --cipher serpent-xts-plain64 /dev/sda2
# Error: cipher serpent-xts-plain64 not available in FIPS mode

# dm-verity: SHA-256 사용 (FIPS 승인)
sudo veritysetup format --hash sha256 /dev/sda1 /dev/sda2
# ✓ FIPS 모드에서 정상 동작

# dm-integrity + HMAC: FIPS 승인 해시 필수
sudo integritysetup format --integrity hmac-sha256 \
    --integrity-key-size 32 --integrity-key-file /path/to/key \
    /dev/sda3

LUKS1 vs LUKS2 비교

LUKS(Linux Unified Key Setup)는 dm-crypt 위에서 키 관리, 헤더 포맷, 다중 패스프레이즈를 표준화한 디스크 암호화 포맷입니다. LUKS2는 JSON 메타데이터, Argon2id KDF, 토큰/세그먼트 추상화, dm-integrity 연동 등 대폭 개선된 2세대 포맷입니다.

# LUKS1 → LUKS2 마이그레이션
# 주의: 반드시 백업 후 진행!
sudo cryptsetup luksDump /dev/sda2 | head -5
# LUKS header information
# Version:        1

# LUKS1 → LUKS2 변환
sudo cryptsetup convert --type luks2 /dev/sda2
sudo cryptsetup luksDump /dev/sda2 | head -5
# LUKS header information
# Version:        2

# LUKS2에서 Argon2id로 KDF 업그레이드
sudo cryptsetup luksConvertKey --pbkdf argon2id \
    --pbkdf-memory 1048576 --pbkdf-parallel 4 /dev/sda2

# LUKS2 JSON 메타데이터 확인
sudo cryptsetup luksDump --dump-json-metadata /dev/sda2 | python3 -m json.tool

# LUKS2 + dm-integrity: 인증 암호화 (AEAD)
# AES-256-GCM: 암호화 + 무결성 동시 보장
sudo cryptsetup luksFormat --type luks2 \
    --cipher aes-gcm-random --key-size 256 \
    --integrity aead \
    --sector-size 4096 \
    /dev/sda2

# 내부적으로 dm-crypt + dm-integrity 스택 생성
sudo cryptsetup open /dev/sda2 secure_vol
dmsetup table secure_vol
# 0 <size> crypt aes-gcm-random ... integrity:28:aead

# 온라인 리키잉 (LUKS2 전용)
# 사용 중인 볼륨의 마스터 키를 교체
sudo cryptsetup reencrypt --cipher aes-xts-plain64 \
    --key-size 512 /dev/sda2

하드웨어 가속

최신 스토리지 컨트롤러와 프로세서는 인라인 암호화 엔진을 내장하여 dm-crypt의 소프트웨어 암호화 오버헤드를 제거합니다. 커널 5.9+의 blk-crypto 프레임워크는 하드웨어/소프트웨어 폴백을 투명하게 통합합니다.

# blk-crypto 하드웨어 지원 확인
# UFS 컨트롤러의 crypto capabilities
cat /sys/block/sda/queue/crypto/modes/AES-256-XTS
# 512  (지원하는 데이터 유닛 크기)

# blk-crypto 프로파일 확인
ls /sys/block/sda/queue/crypto/
# max_dun_bits  modes/  num_keyslots

cat /sys/block/sda/queue/crypto/num_keyslots
# 32  (하드웨어 키 슬롯 수)

# Intel AES-NI 지원 확인
grep -o aes /proc/cpuinfo | head -1
# aes
lsmod | grep aesni
# aesni_intel  ...

/* blk-crypto 키 설정 예시 (커널 내부) */
struct blk_crypto_key key;

/* 키 초기화 */
blk_crypto_init_key(&key, raw_key, 64,
    BLK_ENCRYPTION_MODE_AES_256_XTS, 0,
    512);  /* data_unit_size */

/* bio에 crypto context 설정 */
bio_crypt_set_ctx(bio, &key, dun, GFP_NOIO);

/* blk-crypto가 자동으로 판단:
 * - HW 지원 → 인라인 엔진에 키 프로그래밍
 * - HW 미지원 → blk-crypto-fallback (SW 암호화) */

배치 검증 최적화

dm-verity의 읽기 성능은 Merkle Tree 해시 블록의 I/O 오버헤드에 크게 좌우됩니다. 커널은 해시 블록 프리페치(prefetch), dm-bufio 캐싱, readahead 조합을 통해 대용량 순차 읽기 시나리오에서 검증 오버헤드를 최소화합니다.

/* dm-verity-target.c: 프리페치 워커 */
static void verity_prefetch_io(struct work_struct *work)
{
    struct dm_verity_prefetch_work *pw =
        container_of(work, struct dm_verity_prefetch_work, work);
    struct dm_verity *v = pw->v;
    int i;

    /* Merkle Tree 각 레벨의 해시 블록을 프리페치 */
    for (i = v->levels - 1; i >= 0; i--) {
        sector_t hash_block_start, hash_block_end;

        /* 데이터 블록 범위 → 해시 블록 범위 변환 */
        verity_hash_at_level(v, pw->block, i,
                            &hash_block_start, NULL);
        verity_hash_at_level(v, pw->block + pw->n_blocks - 1,
                            i, &hash_block_end, NULL);

        /* dm-bufio prefetch: 비동기 읽기 요청 */
        dm_bufio_prefetch(v->bufio, hash_block_start,
                         hash_block_end - hash_block_start + 1);
    }

    kfree(pw);
}

/* dm-verity map 경로에서 프리페치 스케줄링 */
static void verity_submit_prefetch(struct dm_verity *v,
    struct dm_verity_io *io)
{
    struct dm_verity_prefetch_work *pw;

    pw = kmalloc(sizeof(*pw), GFP_NOIO);
    if (!pw)
        return;

    INIT_WORK(&pw->work, verity_prefetch_io);
    pw->v = v;
    pw->block = io->block;
    pw->n_blocks = io->n_blocks;
    queue_work(v->verify_wq, &pw->work);
}

# dm-bufio 캐시 상태 확인
cat /sys/module/dm_bufio/parameters/current_allocated_bytes
# 67108864  (64MB)

# 캐시 크기 조정 (해시 트리 전체를 캐싱할 만큼 확보)
# 1GB 디바이스 + SHA-256 + 4KB 블록 = 약 8MB 해시 트리
echo 134217728 | sudo tee /sys/module/dm_bufio/parameters/max_cache_size_bytes
# 128MB로 확대

# readahead 크기 조정 (DM 디바이스)
blockdev --getra /dev/dm-0
# 256  (128KB, 기본값)
sudo blockdev --setra 2048 /dev/dm-0
# 1MB로 확대 → 순차 읽기 성능 향상

# 프리페치 효과 측정: fio 순차 읽기
fio --name=seqread --filename=/dev/dm-0 --rw=read \
    --bs=128k --numjobs=4 --iodepth=32 --size=1G \
    --direct=1 --group_reporting

# dm-bufio 캐시 히트율 확인
cat /sys/module/dm_bufio/parameters/current_allocated_bytes
# peak vs current로 캐시 워킹셋 파악
cat /sys/module/dm_bufio/parameters/peak_allocated_bytes

관련 문서