요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
Target 인자와 운영 규칙
dm-integrity.rst:63-2355개 모드, journal·hash·HMAC·bitmap 옵션, reload 제약과 status를 정리합니다.
On-disk 레이아웃
dm-integrity.rst:236-308Reserved sector, superblock, journal section과 interleaved tag/data run의 형식을 풀이합니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
============
2
dm-integrity
3
============
5
The dm-integrity target emulates a block device that has additional
6
per-sector tags that can be used for storing integrity information.
8
A general problem with storing integrity tags with every sector is that
9
writing the sector and the integrity tag must be atomic - i.e. in case of
10
crash, either both sector and integrity tag or none of them is written.
12
To guarantee write atomicity, the dm-integrity target uses journal, it
13
writes sector data and integrity tags into a journal, commits the journal
14
and then copies the data and integrity tags to their respective location.
16
The dm-integrity target can be used with the dm-crypt target - in this
17
situation the dm-crypt target creates the integrity data and passes them
18
to the dm-integrity target via bio_integrity_payload attached to the bio.
19
In this mode, the dm-crypt and dm-integrity targets provide authenticated
20
disk encryption - if the attacker modifies the encrypted device, an I/O
21
error is returned instead of random data.
23
The dm-integrity target can also be used as a standalone target, in this
24
mode it calculates and verifies the integrity tag internally. In this
25
mode, the dm-integrity target can be used to detect silent data
26
corruption on the disk or in the I/O path.
28
There's an alternate mode of operation where dm-integrity uses a bitmap
29
instead of a journal. If a bit in the bitmap is 1, the corresponding
30
region's data and integrity tags are not synchronized - if the machine
31
crashes, the unsynchronized regions will be recalculated. The bitmap mode
32
is faster than the journal mode, because we don't have to write the data
33
twice, but it is also less reliable, because if data corruption happens
34
when the machine crashes, it may not be detected.
36
When loading the target for the first time, the kernel driver will format
37
the device. But it will only format the device if the superblock contains
38
zeroes. If the superblock is neither valid nor zeroed, the dm-integrity
39
target can't be loaded.
41
Accesses to the on-disk metadata area containing checksums (aka tags) are
42
buffered using dm-bufio. When an access to any given metadata area
43
occurs, each unique metadata area gets its own buffer(s). The buffer size
44
is capped at the size of the metadata area, but may be smaller, thereby
45
requiring multiple buffers to represent the full metadata area. A smaller
46
buffer size will produce a smaller resulting read/write operation to the
47
metadata area for small reads/writes. The metadata is still read even in
48
a full write to the data covered by a single buffer.
50
To use the target for the first time:
52
1. overwrite the superblock with zeroes
53
2. load the dm-integrity target with one-sector size, the kernel driver
54
will format the device
55
3. unload the dm-integrity target
56
4. read the "provided_data_sectors" value from the superblock
57
5. load the dm-integrity target with the target size
58
"provided_data_sectors"
59
6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target
60
with the size "provided_data_sectors"
63
Target arguments:
65
1. the underlying block device
67
2. the number of reserved sector at the beginning of the device - the
68
dm-integrity won't read of write these sectors
70
3. the size of the integrity tag (if "-" is used, the size is taken from
71
the internal-hash algorithm)
73
4. mode:
75
D - direct writes (without journal)
76
in this mode, journaling is
77
not used and data sectors and integrity tags are written
78
separately. In case of crash, it is possible that the data
79
and integrity tag doesn't match.
80
J - journaled writes
81
data and integrity tags are written to the
82
journal and atomicity is guaranteed. In case of crash,
83
either both data and tag or none of them are written. The
84
journaled mode degrades write throughput twice because the
85
data have to be written twice.
86
B - bitmap mode - data and metadata are written without any
87
synchronization, the driver maintains a bitmap of dirty
88
regions where data and metadata don't match. This mode can
89
only be used with internal hash.
90
R - recovery mode - in this mode, journal is not replayed,
91
checksums are not checked and writes to the device are not
92
allowed. This mode is useful for data recovery if the
93
device cannot be activated in any of the other standard
94
modes.
95
I - inline mode - in this mode, dm-integrity will store integrity
96
data directly in the underlying device sectors.
97
The underlying device must have an integrity profile that
98
allows storing user integrity data and provides enough
99
space for the selected integrity tag.
101
5. the number of additional arguments
103
Additional arguments:
105
journal_sectors:number
106
The size of journal, this argument is used only if formatting the
107
device. If the device is already formatted, the value from the
108
superblock is used.
110
interleave_sectors:number (default 32768)
111
The number of interleaved sectors. This values is rounded down to
112
a power of two. If the device is already formatted, the value from
113
the superblock is used.
115
meta_device:device
116
Don't interleave the data and metadata on the device. Use a
117
separate device for metadata.
119
buffer_sectors:number (default 128)
120
The number of sectors in one metadata buffer. The value is rounded
121
down to a power of two.
123
journal_watermark:number (default 50)
124
The journal watermark in percents. When the size of the journal
125
exceeds this watermark, the thread that flushes the journal will
126
be started.
128
commit_time:number (default 10000)
129
Commit time in milliseconds. When this time passes, the journal is
130
written. The journal is also written immediately if the FLUSH
131
request is received.
133
internal_hash:algorithm(:key) (the key is optional)
134
Use internal hash or crc.
135
When this argument is used, the dm-integrity target won't accept
136
integrity tags from the upper target, but it will automatically
137
generate and verify the integrity tags.
139
You can use a crc algorithm (such as crc32), then integrity target
140
will protect the data against accidental corruption.
141
You can also use a hmac algorithm (for example
142
"hmac(sha256):0123456789abcdef"), in this mode it will provide
143
cryptographic authentication of the data without encryption.
145
When this argument is not used, the integrity tags are accepted
146
from an upper layer target, such as dm-crypt. The upper layer
147
target should check the validity of the integrity tags.
149
recalculate
150
Recalculate the integrity tags automatically. It is only valid
151
when using internal hash.
153
journal_crypt:algorithm(:key) (the key is optional)
154
Encrypt the journal using given algorithm to make sure that the
155
attacker can't read the journal. You can use a block cipher here
156
(such as "cbc(aes)") or a stream cipher (for example "chacha20"
157
or "ctr(aes)").
159
The journal contains history of last writes to the block device,
160
an attacker reading the journal could see the last sector numbers
161
that were written. From the sector numbers, the attacker can infer
162
the size of files that were written. To protect against this
163
situation, you can encrypt the journal.
165
journal_mac:algorithm(:key) (the key is optional)
166
Protect sector numbers in the journal from accidental or malicious
167
modification. To protect against accidental modification, use a
168
crc algorithm, to protect against malicious modification, use a
169
hmac algorithm with a key.
171
This option is not needed when using internal-hash because in this
172
mode, the integrity of journal entries is checked when replaying
173
the journal. Thus, modified sector number would be detected at
174
this stage.
176
block_size:number (default 512)
177
The size of a data block in bytes. The larger the block size the
178
less overhead there is for per-block integrity metadata.
179
Supported values are 512, 1024, 2048 and 4096 bytes.
181
sectors_per_bit:number
182
In the bitmap mode, this parameter specifies the number of
183
512-byte sectors that corresponds to one bitmap bit.
185
bitmap_flush_interval:number
186
The bitmap flush interval in milliseconds. The metadata buffers
187
are synchronized when this interval expires.
189
allow_discards
190
Allow block discard requests (a.k.a. TRIM) for the integrity device.
191
Discards are only allowed to devices using internal hash.
193
fix_padding
194
Use a smaller padding of the tag area that is more
195
space-efficient. If this option is not present, large padding is
196
used - that is for compatibility with older kernels.
198
fix_hmac
199
Improve security of internal_hash and journal_mac:
201
- the section number is mixed to the mac, so that an attacker can't
202
copy sectors from one journal section to another journal section
203
- the superblock is protected by journal_mac
204
- a 16-byte salt stored in the superblock is mixed to the mac, so
205
that the attacker can't detect that two disks have the same hmac
206
key and also to disallow the attacker to move sectors from one
207
disk to another
209
legacy_recalculate
210
Allow recalculating of volumes with HMAC keys. This is disabled by
211
default for security reasons - an attacker could modify the volume,
212
set recalc_sector to zero, and the kernel would not detect the
213
modification.
215
The journal mode (D/J), buffer_sectors, journal_watermark, commit_time and
216
allow_discards can be changed when reloading the target (load an inactive
217
table and swap the tables with suspend and resume). The other arguments
218
should not be changed when reloading the target because the layout of disk
219
data depend on them and the reloaded target would be non-functional.
221
For example, on a device using the default interleave_sectors of 32768, a
222
block_size of 512, and an internal_hash of crc32c with a tag size of 4
223
bytes, it will take 128 KiB of tags to track a full data area, requiring
224
256 sectors of metadata per data area. With the default buffer_sectors of
225
128, that means there will be 2 buffers per metadata area, or 2 buffers
226
per 16 MiB of data.
228
Status line:
230
1. the number of integrity mismatches
231
2. provided data sectors - that is the number of sectors that the user
232
could use
233
3. the current recalculating position (or '-' if we didn't recalculate)
236
The layout of the formatted block device:
238
* reserved sectors
239
(they are not used by this target, they can be used for
240
storing LUKS metadata or for other purpose), the size of the reserved
241
area is specified in the target arguments
243
* superblock (4kiB)
244
* magic string - identifies that the device was formatted
245
* version
246
* log2(interleave sectors)
247
* integrity tag size
248
* the number of journal sections
249
* provided data sectors - the number of sectors that this target
250
provides (i.e. the size of the device minus the size of all
251
metadata and padding). The user of this target should not send
252
bios that access data beyond the "provided data sectors" limit.
253
* flags
254
SB_FLAG_HAVE_JOURNAL_MAC
255
- a flag is set if journal_mac is used
256
SB_FLAG_RECALCULATING
257
- recalculating is in progress
258
SB_FLAG_DIRTY_BITMAP
259
- journal area contains the bitmap of dirty
260
blocks
261
* log2(sectors per block)
262
* a position where recalculating finished
263
* journal
264
The journal is divided into sections, each section contains:
266
* metadata area (4kiB), it contains journal entries
268
- every journal entry contains:
270
* logical sector (specifies where the data and tag should
271
be written)
272
* last 8 bytes of data
273
* integrity tag (the size is specified in the superblock)
275
- every metadata sector ends with
277
* mac (8-bytes), all the macs in 8 metadata sectors form a
278
64-byte value. It is used to store hmac of sector
279
numbers in the journal section, to protect against a
280
possibility that the attacker tampers with sector
281
numbers in the journal.
282
* commit id
284
* data area (the size is variable; it depends on how many journal
285
entries fit into the metadata area)
287
- every sector in the data area contains:
289
* data (504 bytes of data, the last 8 bytes are stored in
290
the journal entry)
291
* commit id
293
To test if the whole journal section was written correctly, every
294
512-byte sector of the journal ends with 8-byte commit id. If the
295
commit id matches on all sectors in a journal section, then it is
296
assumed that the section was written correctly. If the commit id
297
doesn't match, the section was written partially and it should not
298
be replayed.
300
* one or more runs of interleaved tags and data.
301
Each run contains:
303
* tag area - it contains integrity tags. There is one tag for each
304
sector in the data area. The size of this area is always 4KiB or
305
greater.
306
* data area - it contains data sectors. The number of data sectors
307
in one run must be a power of two. log2 of this value is stored
308
in the superblock.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Sector tag, 원자성, journal과 bitmap 동작 모델
1-49`dm-integrity` target은 무결성 정보를 저장할 수 있는 sector별 추가 tag를 가진 block 장치를 에뮬레이션합니다.
각 sector와 함께 integrity tag를 저장할 때의 일반적인 문제는 sector 쓰기와 tag 쓰기가 원자적이어야 한다는 점입니다. 즉 crash가 발생하면 sector와 tag가 모두 기록되거나, 둘 다 기록되지 않아야 합니다.
쓰기 원자성을 보장하기 위해 `dm-integrity`는 sector data와 integrity tag를 journal에 쓰고 journal을 commit한 다음, data와 tag를 각각의 최종 위치로 복사합니다.
Sector data + integrity tag 수신→Journal에 함께 기록→Journal commit→각 최종 위치로 복사→원자적 완료
Data와 tag를 하나의 commit 단위로 만든 뒤 최종 영역에 반영합니다.
`dm-crypt`와 함께 사용할 때는 `dm-crypt`가 integrity data를 만들고 bio에 연결된 `bio_integrity_payload`를 통해 `dm-integrity`로 전달합니다. 두 target은 authenticated disk encryption을 제공하므로 공격자가 암호화 장치를 변경하면 임의 data 대신 I/O 오류가 반환됩니다.
독립 target으로 사용할 수도 있습니다. 이 모드에서는 `dm-integrity`가 내부에서 tag를 계산하고 검증해 디스크 또는 I/O 경로의 silent data corruption을 탐지합니다.
대체 동작인 bitmap 모드는 journal 대신 dirty-region bitmap을 사용합니다. Bit가 1인 영역은 data와 tag가 동기화되지 않은 상태이며 crash 후 다시 계산됩니다. Data를 두 번 쓸 필요가 없어 journal 모드보다 빠르지만, crash와 동시에 생긴 data corruption을 탐지하지 못할 수 있어 신뢰성은 낮습니다.
Target을 처음 load하면 커널 드라이버가 장치를 format합니다. 단 superblock이 모두 0일 때만 format하며, superblock이 유효하지도 않고 0으로 지워져 있지도 않으면 target을 load할 수 없습니다.
Checksum, 즉 tag가 있는 on-disk metadata 영역 접근은 `dm-bufio`로 buffering합니다. 접근한 고유 metadata 영역마다 전용 buffer가 생깁니다. Buffer는 metadata 영역 크기를 넘지 않지만 더 작을 수 있어 한 영역을 여러 buffer가 나타낼 수 있습니다. 작은 buffer는 작은 read/write에서 metadata I/O 크기를 줄이지만, 한 buffer가 담당하는 data 전체를 쓰는 경우에도 metadata는 읽습니다.
최초 format과 provided_data_sectors 적용 절차
50-62Target을 처음 사용할 때는 실제 제공 가능한 data sector 수를 superblock에서 확인한 뒤 최종 크기로 다시 load해야 합니다.
Superblock을 0으로 덮어쓰기→1-sector 크기로 dm-integrity load→커널이 장치 format→dm-integrity unload→superblock의 `provided_data_sectors` 읽기→해당 크기로 dm-integrity 재-load
`provided_data_sectors` 확인→dm-crypt를 함께 쓸 경우 같은 크기로 load
한 sector 임시 mapping으로 format한 뒤 superblock이 계산한 실제 data 용량을 사용합니다.
이 순서는 metadata와 padding을 제외한 안전한 data 범위를 확정합니다. `dm-crypt`를 위에 쌓는 경우에도 반드시 동일한 `provided_data_sectors` 크기를 사용합니다.
기본 target 인자와 D·J·B·R·I 모드
63-102Target table은 underlying block device, 시작 부분의 reserved sector 수, integrity tag 크기, mode, 추가 인자 개수를 순서대로 받습니다. Reserved sector는 `dm-integrity`가 읽거나 쓰지 않으며, tag 크기에 `-`를 쓰면 `internal_hash` 알고리즘에서 크기를 가져옵니다.
순서인자의미
1underlying block deviceData와 metadata를 저장할 장치
2reserved sector 수장치 시작에서 target이 접근하지 않을 sector 수
3integrity tag 크기Byte 단위 tag 크기 또는 internal hash에서 가져오는 `-`
4mode`D`, `J`, `B`, `R`, `I` 중 하나
5추가 인자 수뒤따르는 optional 인자의 개수
On-disk 배치와 동작 모드를 결정하는 필수 필드입니다.
Mode동작제약과 특성
`D` directJournal 없이 data sector와 tag를 따로 기록Crash 시 data와 tag가 불일치할 수 있음
`J` journaledData와 tag를 journal에 쓰고 원자적으로 commit둘 다 또는 둘 다 아님을 보장하지만 data를 두 번 써 처리량이 절반 수준으로 감소
`B` bitmap동기화 없이 data와 metadata를 쓰고 dirty region을 bitmap으로 추적`internal_hash`와만 사용 가능
`R` recoveryJournal replay와 checksum 검사를 하지 않음쓰기를 금지하며 표준 모드로 활성화할 수 없는 장치의 data 복구에 사용
`I` inlineUnderlying sector 안에 integrity data를 직접 저장User integrity data를 허용하고 선택한 tag 공간이 충분한 integrity profile 필요
원자성, 복구, inline 저장 방식의 차이를 비교합니다.
Journal 배치·buffer·commit과 internal_hash
103-148다음 optional 인자는 format 시의 journal·metadata 배치, buffer 크기, commit 시점과 내부 tag 생성 방식을 제어합니다.
인자기본값동작
`journal_sectors:number`지정값Format할 journal 크기. 이미 format된 장치는 superblock 값 사용
`interleave_sectors:number`32768Interleave sector 수. 2의 거듭제곱으로 내림하고 기존 장치는 superblock 값 사용
`meta_device:device`없음Data와 metadata를 interleave하지 않고 별도 metadata 장치 사용
`buffer_sectors:number`128Metadata buffer당 sector 수. 2의 거듭제곱으로 내림
`journal_watermark:number`50%Journal 사용량이 이 비율을 넘으면 flush thread 시작
`commit_time:number`10000 ms시간이 지나면 journal 기록. FLUSH request가 오면 즉시 기록
이미 format된 장치는 일부 값을 table이 아니라 superblock에서 읽습니다.
`internal_hash:algorithm(:key)`는 선택적인 key와 함께 내부 hash 또는 CRC를 사용합니다. 이 인자를 쓰면 상위 target의 integrity tag를 받지 않고 `dm-integrity`가 tag를 자동 생성·검증합니다.
형식보호 수준예
CRC algorithm우발적 data corruption 탐지`crc32`
HMAC algorithm + key암호화 없이 data의 암호학적 인증`hmac(sha256):0123456789abcdef`
`internal_hash` 없음상위 target이 tag를 제공하고 유효성을 검사`dm-crypt`
오류 탐지 목적과 암호학적 인증 목적에 맞춰 알고리즘을 고릅니다.
재계산·journal 보호·bitmap·호환 옵션과 reload 규칙
149-220인자설명
`recalculate``internal_hash` 사용 시 integrity tag를 자동으로 다시 계산
`journal_crypt:algorithm(:key)``cbc(aes)`, `chacha20`, `ctr(aes)` 등으로 journal 내용을 암호화
`journal_mac:algorithm(:key)`CRC로 우발적 변경을, key가 있는 HMAC으로 악의적 sector-number 변경을 방지
`block_size:number`Data block byte 크기. 기본 512, 지원값 512·1024·2048·4096
`sectors_per_bit:number`Bitmap 한 bit에 대응하는 512-byte sector 수
`bitmap_flush_interval:number`Metadata buffer를 동기화하는 millisecond 간격
`allow_discards`TRIM 요청 허용. `internal_hash` 장치에서만 가능
`fix_padding`Tag 영역의 더 작고 공간 효율적인 padding 사용. 없으면 구형 커널 호환용 큰 padding 사용
`legacy_recalculate`HMAC key가 있는 volume 재계산 허용. 보안상 기본 비활성화
Tag 재계산, journal 암호화·인증, bitmap과 discard 동작을 제어합니다.
Journal에는 마지막 block 쓰기의 이력과 sector 번호가 남아 파일 크기를 추론할 수 있으므로, 노출을 막으려면 `journal_crypt`로 암호화합니다. `journal_mac`은 journal의 sector 번호가 우발적 또는 악의적으로 변조되는 것을 막습니다.
최근 write 이력과 sector 번호→`journal_crypt`→공격자의 파일 크기 추론 방지
Journal sector 번호→`journal_mac` CRC/HMAC→우발적·악의적 위치 변조 탐지
`internal_hash` 사용→Replay 중 journal entry 무결성 검사→`journal_mac`이 별도로 필요하지 않음
내용 노출과 위치 변조는 서로 다른 옵션으로 방어합니다.
`fix_hmac`은 `internal_hash`와 `journal_mac`의 보안을 강화합니다.
보강효과
Section 번호를 MAC에 혼합Journal section 사이의 sector 복사 방지
Superblock을 `journal_mac`으로 보호장치 형식 정보 변조 탐지
Superblock의 16-byte salt를 MAC에 혼합같은 HMAC key를 쓰는 두 디스크 탐지와 디스크 간 sector 이동 방지
복사·교체 공격과 동일 key 상관관계를 줄입니다.
`legacy_recalculate`이 기본 비활성화인 이유는 공격자가 volume을 수정하고 `recalc_sector`를 0으로 설정하면 커널이 변경을 탐지하지 못할 수 있기 때문입니다.
구분인자이유
변경 가능Mode `D/J`, `buffer_sectors`, `journal_watermark`, `commit_time`, `allow_discards`On-disk layout을 바꾸지 않는 runtime 동작
변경 금지그 밖의 모든 layout 관련 인자Disk data 배치가 달라져 reload한 target이 동작하지 않음
Inactive table을 load하고 suspend/resume으로 교체할 때 적용되는 규칙입니다.
Metadata buffer 산정 예와 status line
221-235기본 `interleave_sectors=32768`, `block_size=512`, `internal_hash=crc32c`, tag 크기 4 byte인 장치에서는 하나의 전체 data 영역을 추적하는 tag가 128 KiB 필요합니다. 이는 data 영역당 256 metadata sector입니다.
32768 sectors × 512 bytes→16 MiB data→4-byte tag × 32768→128 KiB tags→256 metadata sectors→`buffer_sectors=128`→2 buffers
16 MiB data 영역마다 두 개의 metadata buffer가 필요합니다.
따라서 기본 `buffer_sectors=128`에서는 metadata 영역마다 2개, 즉 data 16 MiB마다 2개의 buffer가 생깁니다.
순서값
1Integrity mismatch 수
2사용자가 접근할 수 있는 `provided data sectors`
3현재 재계산 위치. 재계산하지 않았다면 `-`
Target status는 오류 수, 제공 용량과 재계산 진행 위치를 반환합니다.
Formatted block device의 reserved 영역과 superblock
236-262Reserved sectors→Superblock 4 KiB→Journal→Tag/Data interleaved runs
Reserved 영역 뒤에 형식 정보를 담은 4 KiB superblock과 journal, interleaved run이 배치됩니다.
Reserved sector는 target이 사용하지 않으며 LUKS metadata 등 다른 목적으로 쓸 수 있습니다. 크기는 target 인자에서 지정합니다.
필드의미
Magic string장치가 format되었음을 식별
VersionOn-disk 형식 버전
`log2(interleave sectors)`Interleave 크기의 지수
Integrity tag sizeTag byte 크기
Journal section 수Journal 분할 개수
`provided data sectors`Metadata와 padding을 제외하고 target이 제공하는 sector 수. 이 한계를 넘는 bio를 보내면 안 됨
`SB_FLAG_HAVE_JOURNAL_MAC``journal_mac` 사용 여부
`SB_FLAG_RECALCULATING`재계산 진행 중
`SB_FLAG_DIRTY_BITMAP`Journal 영역에 dirty-block bitmap이 있음
`log2(sectors per block)`Block당 sector 수의 지수
Recalculation position재계산이 완료된 위치
Format 식별, disk layout, 제공 용량과 runtime 상태를 기록합니다.
Journal section과 interleaved tag/data run의 세부 레이아웃
263-308Journal은 여러 section으로 나뉘며 각 section은 4 KiB metadata 영역과 가변 크기 data 영역을 가집니다.
영역저장 내용
Metadata area 4 KiBJournal entry 목록
각 journal entry최종 data/tag 위치를 나타내는 logical sector, data 마지막 8 byte, integrity tag
각 metadata sector 끝8-byte MAC과 commit ID. 8개 metadata sector의 MAC이 64-byte HMAC 값을 구성
Data area의 각 sectorData 504 byte, 나머지 8 byte는 journal entry에 저장, sector 끝에 commit ID
Entry와 sector 끝의 commit 정보로 완전한 section 쓰기를 판정합니다.
Journal section의 모든 512-byte sector는 8-byte commit ID로 끝납니다. Section의 모든 sector에서 ID가 같으면 완전히 기록된 것으로 간주합니다. 일치하지 않으면 부분 기록이므로 replay하지 않습니다. Metadata MAC은 공격자가 journal sector 번호를 변조하는 것을 방지합니다.
Journal section의 모든 512-byte sector 읽기→8-byte commit ID 비교→모두 일치→완전한 section으로 replay
Commit ID 비교→하나라도 불일치→부분 기록으로 판정→Replay하지 않음
Section 전체의 commit ID 일치 여부가 원자적 기록의 증거가 됩니다.
Journal 뒤에는 하나 이상의 interleaved tag/data run이 옵니다. 각 run의 tag 영역에는 data 영역의 sector마다 하나의 integrity tag가 있으며 크기는 항상 4 KiB 이상입니다. Data 영역의 sector 수는 반드시 2의 거듭제곱이고, 그 값의 `log2`를 superblock에 저장합니다.
무결성 동작 모델
dm-integrity.rst:1-62Tag 원자성, dm-crypt 연동, bitmap tradeoff와 최초 format 절차를 설명합니다.