rjw | 1f88458 | 2022-01-06 17:20:42 +0800 | [diff] [blame^] | 1 | # |
| 2 | # Block device driver configuration |
| 3 | # |
| 4 | |
| 5 | menuconfig MD |
| 6 | bool "Multiple devices driver support (RAID and LVM)" |
| 7 | depends on BLOCK |
| 8 | select SRCU |
| 9 | help |
| 10 | Support multiple physical spindles through a single logical device. |
| 11 | Required for RAID and logical volume management. |
| 12 | |
| 13 | if MD |
| 14 | |
| 15 | config BLK_DEV_MD |
| 16 | tristate "RAID support" |
| 17 | ---help--- |
| 18 | This driver lets you combine several hard disk partitions into one |
| 19 | logical block device. This can be used to simply append one |
| 20 | partition to another one or to combine several redundant hard disks |
| 21 | into a RAID1/4/5 device so as to provide protection against hard |
| 22 | disk failures. This is called "Software RAID" since the combining of |
| 23 | the partitions is done by the kernel. "Hardware RAID" means that the |
| 24 | combining is done by a dedicated controller; if you have such a |
| 25 | controller, you do not need to say Y here. |
| 26 | |
| 27 | More information about Software RAID on Linux is contained in the |
| 28 | Software RAID mini-HOWTO, available from |
| 29 | <http://www.tldp.org/docs.html#howto>. There you will also learn |
| 30 | where to get the supporting user space utilities raidtools. |
| 31 | |
| 32 | If unsure, say N. |
| 33 | |
| 34 | config MD_AUTODETECT |
| 35 | bool "Autodetect RAID arrays during kernel boot" |
| 36 | depends on BLK_DEV_MD=y |
| 37 | default y |
| 38 | ---help--- |
| 39 | If you say Y here, then the kernel will try to autodetect raid |
| 40 | arrays as part of its boot process. |
| 41 | |
| 42 | If you don't use raid and say Y, this autodetection can cause |
| 43 | a several-second delay in the boot time due to various |
| 44 | synchronisation steps that are part of this step. |
| 45 | |
| 46 | If unsure, say Y. |
| 47 | |
| 48 | config MD_LINEAR |
| 49 | tristate "Linear (append) mode" |
| 50 | depends on BLK_DEV_MD |
| 51 | ---help--- |
| 52 | If you say Y here, then your multiple devices driver will be able to |
| 53 | use the so-called linear mode, i.e. it will combine the hard disk |
| 54 | partitions by simply appending one to the other. |
| 55 | |
| 56 | To compile this as a module, choose M here: the module |
| 57 | will be called linear. |
| 58 | |
| 59 | If unsure, say Y. |
| 60 | |
| 61 | config MD_RAID0 |
| 62 | tristate "RAID-0 (striping) mode" |
| 63 | depends on BLK_DEV_MD |
| 64 | ---help--- |
| 65 | If you say Y here, then your multiple devices driver will be able to |
| 66 | use the so-called raid0 mode, i.e. it will combine the hard disk |
| 67 | partitions into one logical device in such a fashion as to fill them |
| 68 | up evenly, one chunk here and one chunk there. This will increase |
| 69 | the throughput rate if the partitions reside on distinct disks. |
| 70 | |
| 71 | Information about Software RAID on Linux is contained in the |
| 72 | Software-RAID mini-HOWTO, available from |
| 73 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 74 | learn where to get the supporting user space utilities raidtools. |
| 75 | |
| 76 | To compile this as a module, choose M here: the module |
| 77 | will be called raid0. |
| 78 | |
| 79 | If unsure, say Y. |
| 80 | |
| 81 | config MD_RAID1 |
| 82 | tristate "RAID-1 (mirroring) mode" |
| 83 | depends on BLK_DEV_MD |
| 84 | ---help--- |
| 85 | A RAID-1 set consists of several disk drives which are exact copies |
| 86 | of each other. In the event of a mirror failure, the RAID driver |
| 87 | will continue to use the operational mirrors in the set, providing |
| 88 | an error free MD (multiple device) to the higher levels of the |
| 89 | kernel. In a set with N drives, the available space is the capacity |
| 90 | of a single drive, and the set protects against a failure of (N - 1) |
| 91 | drives. |
| 92 | |
| 93 | Information about Software RAID on Linux is contained in the |
| 94 | Software-RAID mini-HOWTO, available from |
| 95 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 96 | learn where to get the supporting user space utilities raidtools. |
| 97 | |
| 98 | If you want to use such a RAID-1 set, say Y. To compile this code |
| 99 | as a module, choose M here: the module will be called raid1. |
| 100 | |
| 101 | If unsure, say Y. |
| 102 | |
| 103 | config MD_RAID10 |
| 104 | tristate "RAID-10 (mirrored striping) mode" |
| 105 | depends on BLK_DEV_MD |
| 106 | ---help--- |
| 107 | RAID-10 provides a combination of striping (RAID-0) and |
| 108 | mirroring (RAID-1) with easier configuration and more flexible |
| 109 | layout. |
| 110 | Unlike RAID-0, but like RAID-1, RAID-10 requires all devices to |
| 111 | be the same size (or at least, only as much as the smallest device |
| 112 | will be used). |
| 113 | RAID-10 provides a variety of layouts that provide different levels |
| 114 | of redundancy and performance. |
| 115 | |
| 116 | RAID-10 requires mdadm-1.7.0 or later, available at: |
| 117 | |
| 118 | https://www.kernel.org/pub/linux/utils/raid/mdadm/ |
| 119 | |
| 120 | If unsure, say Y. |
| 121 | |
| 122 | config MD_RAID456 |
| 123 | tristate "RAID-4/RAID-5/RAID-6 mode" |
| 124 | depends on BLK_DEV_MD |
| 125 | select RAID6_PQ |
| 126 | select LIBCRC32C |
| 127 | select ASYNC_MEMCPY |
| 128 | select ASYNC_XOR |
| 129 | select ASYNC_PQ |
| 130 | select ASYNC_RAID6_RECOV |
| 131 | ---help--- |
| 132 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 133 | the capacity of C * (N - 1) MB, and protects against a failure |
| 134 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 135 | contain data sectors, and one drive contains the parity protection. |
| 136 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 137 | while a RAID-5 set distributes the parity across the drives in one |
| 138 | of the available parity distribution methods. |
| 139 | |
| 140 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 141 | provides the capacity of C * (N - 2) MB, and protects |
| 142 | against a failure of any two drives. For a given sector |
| 143 | (row) number, (N - 2) drives contain data sectors, and two |
| 144 | drives contains two independent redundancy syndromes. Like |
| 145 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 146 | in one of the available parity distribution methods. |
| 147 | |
| 148 | Information about Software RAID on Linux is contained in the |
| 149 | Software-RAID mini-HOWTO, available from |
| 150 | <http://www.tldp.org/docs.html#howto>. There you will also |
| 151 | learn where to get the supporting user space utilities raidtools. |
| 152 | |
| 153 | If you want to use such a RAID-4/RAID-5/RAID-6 set, say Y. To |
| 154 | compile this code as a module, choose M here: the module |
| 155 | will be called raid456. |
| 156 | |
| 157 | If unsure, say Y. |
| 158 | |
| 159 | config MD_MULTIPATH |
| 160 | tristate "Multipath I/O support" |
| 161 | depends on BLK_DEV_MD |
| 162 | help |
| 163 | MD_MULTIPATH provides a simple multi-path personality for use |
| 164 | the MD framework. It is not under active development. New |
| 165 | projects should consider using DM_MULTIPATH which has more |
| 166 | features and more testing. |
| 167 | |
| 168 | If unsure, say N. |
| 169 | |
| 170 | config MD_FAULTY |
| 171 | tristate "Faulty test module for MD" |
| 172 | depends on BLK_DEV_MD |
| 173 | help |
| 174 | The "faulty" module allows for a block device that occasionally returns |
| 175 | read or write errors. It is useful for testing. |
| 176 | |
| 177 | In unsure, say N. |
| 178 | |
| 179 | |
| 180 | config MD_CLUSTER |
| 181 | tristate "Cluster Support for MD (EXPERIMENTAL)" |
| 182 | depends on BLK_DEV_MD |
| 183 | depends on DLM |
| 184 | default n |
| 185 | ---help--- |
| 186 | Clustering support for MD devices. This enables locking and |
| 187 | synchronization across multiple systems on the cluster, so all |
| 188 | nodes in the cluster can access the MD devices simultaneously. |
| 189 | |
| 190 | This brings the redundancy (and uptime) of RAID levels across the |
| 191 | nodes of the cluster. |
| 192 | |
| 193 | If unsure, say N. |
| 194 | |
| 195 | source "drivers/md/bcache/Kconfig" |
| 196 | |
| 197 | config BLK_DEV_DM_BUILTIN |
| 198 | bool |
| 199 | |
| 200 | config BLK_DEV_DM |
| 201 | tristate "Device mapper support" |
| 202 | select BLK_DEV_DM_BUILTIN |
| 203 | select DAX |
| 204 | ---help--- |
| 205 | Device-mapper is a low level volume manager. It works by allowing |
| 206 | people to specify mappings for ranges of logical sectors. Various |
| 207 | mapping types are available, in addition people may write their own |
| 208 | modules containing custom mappings if they wish. |
| 209 | |
| 210 | Higher level volume managers such as LVM2 use this driver. |
| 211 | |
| 212 | To compile this as a module, choose M here: the module will be |
| 213 | called dm-mod. |
| 214 | |
| 215 | If unsure, say N. |
| 216 | |
| 217 | config DM_MQ_DEFAULT |
| 218 | bool "request-based DM: use blk-mq I/O path by default" |
| 219 | depends on BLK_DEV_DM |
| 220 | ---help--- |
| 221 | This option enables the blk-mq based I/O path for request-based |
| 222 | DM devices by default. With the option the dm_mod.use_blk_mq |
| 223 | module/boot option defaults to Y, without it to N, but it can |
| 224 | still be overriden either way. |
| 225 | |
| 226 | If unsure say N. |
| 227 | |
| 228 | config DM_DEBUG |
| 229 | bool "Device mapper debugging support" |
| 230 | depends on BLK_DEV_DM |
| 231 | ---help--- |
| 232 | Enable this for messages that may help debug device-mapper problems. |
| 233 | |
| 234 | If unsure, say N. |
| 235 | |
| 236 | config DM_BUFIO |
| 237 | tristate |
| 238 | depends on BLK_DEV_DM |
| 239 | ---help--- |
| 240 | This interface allows you to do buffered I/O on a device and acts |
| 241 | as a cache, holding recently-read blocks in memory and performing |
| 242 | delayed writes. |
| 243 | |
| 244 | config DM_DEBUG_BLOCK_MANAGER_LOCKING |
| 245 | bool "Block manager locking" |
| 246 | depends on DM_BUFIO |
| 247 | ---help--- |
| 248 | Block manager locking can catch various metadata corruption issues. |
| 249 | |
| 250 | If unsure, say N. |
| 251 | |
| 252 | config DM_DEBUG_BLOCK_STACK_TRACING |
| 253 | bool "Keep stack trace of persistent data block lock holders" |
| 254 | depends on STACKTRACE_SUPPORT && DM_DEBUG_BLOCK_MANAGER_LOCKING |
| 255 | select STACKTRACE |
| 256 | ---help--- |
| 257 | Enable this for messages that may help debug problems with the |
| 258 | block manager locking used by thin provisioning and caching. |
| 259 | |
| 260 | If unsure, say N. |
| 261 | |
| 262 | config DM_BIO_PRISON |
| 263 | tristate |
| 264 | depends on BLK_DEV_DM |
| 265 | ---help--- |
| 266 | Some bio locking schemes used by other device-mapper targets |
| 267 | including thin provisioning. |
| 268 | |
| 269 | source "drivers/md/persistent-data/Kconfig" |
| 270 | |
| 271 | config DM_CRYPT |
| 272 | tristate "Crypt target support" |
| 273 | depends on BLK_DEV_DM |
| 274 | select CRYPTO |
| 275 | select CRYPTO_CBC |
| 276 | ---help--- |
| 277 | This device-mapper target allows you to create a device that |
| 278 | transparently encrypts the data on it. You'll need to activate |
| 279 | the ciphers you're going to use in the cryptoapi configuration. |
| 280 | |
| 281 | For further information on dm-crypt and userspace tools see: |
| 282 | <https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt> |
| 283 | |
| 284 | To compile this code as a module, choose M here: the module will |
| 285 | be called dm-crypt. |
| 286 | |
| 287 | If unsure, say N. |
| 288 | |
| 289 | config DM_SNAPSHOT |
| 290 | tristate "Snapshot target" |
| 291 | depends on BLK_DEV_DM |
| 292 | select DM_BUFIO |
| 293 | ---help--- |
| 294 | Allow volume managers to take writable snapshots of a device. |
| 295 | |
| 296 | config DM_THIN_PROVISIONING |
| 297 | tristate "Thin provisioning target" |
| 298 | depends on BLK_DEV_DM |
| 299 | select DM_PERSISTENT_DATA |
| 300 | select DM_BIO_PRISON |
| 301 | ---help--- |
| 302 | Provides thin provisioning and snapshots that share a data store. |
| 303 | |
| 304 | config DM_CACHE |
| 305 | tristate "Cache target (EXPERIMENTAL)" |
| 306 | depends on BLK_DEV_DM |
| 307 | default n |
| 308 | select DM_PERSISTENT_DATA |
| 309 | select DM_BIO_PRISON |
| 310 | ---help--- |
| 311 | dm-cache attempts to improve performance of a block device by |
| 312 | moving frequently used data to a smaller, higher performance |
| 313 | device. Different 'policy' plugins can be used to change the |
| 314 | algorithms used to select which blocks are promoted, demoted, |
| 315 | cleaned etc. It supports writeback and writethrough modes. |
| 316 | |
| 317 | config DM_CACHE_SMQ |
| 318 | tristate "Stochastic MQ Cache Policy (EXPERIMENTAL)" |
| 319 | depends on DM_CACHE |
| 320 | default y |
| 321 | ---help--- |
| 322 | A cache policy that uses a multiqueue ordered by recent hits |
| 323 | to select which blocks should be promoted and demoted. |
| 324 | This is meant to be a general purpose policy. It prioritises |
| 325 | reads over writes. This SMQ policy (vs MQ) offers the promise |
| 326 | of less memory utilization, improved performance and increased |
| 327 | adaptability in the face of changing workloads. |
| 328 | |
| 329 | config DM_ERA |
| 330 | tristate "Era target (EXPERIMENTAL)" |
| 331 | depends on BLK_DEV_DM |
| 332 | default n |
| 333 | select DM_PERSISTENT_DATA |
| 334 | select DM_BIO_PRISON |
| 335 | ---help--- |
| 336 | dm-era tracks which parts of a block device are written to |
| 337 | over time. Useful for maintaining cache coherency when using |
| 338 | vendor snapshots. |
| 339 | |
| 340 | config DM_MIRROR |
| 341 | tristate "Mirror target" |
| 342 | depends on BLK_DEV_DM |
| 343 | ---help--- |
| 344 | Allow volume managers to mirror logical volumes, also |
| 345 | needed for live data migration tools such as 'pvmove'. |
| 346 | |
| 347 | config DM_LOG_USERSPACE |
| 348 | tristate "Mirror userspace logging" |
| 349 | depends on DM_MIRROR && NET |
| 350 | select CONNECTOR |
| 351 | ---help--- |
| 352 | The userspace logging module provides a mechanism for |
| 353 | relaying the dm-dirty-log API to userspace. Log designs |
| 354 | which are more suited to userspace implementation (e.g. |
| 355 | shared storage logs) or experimental logs can be implemented |
| 356 | by leveraging this framework. |
| 357 | |
| 358 | config DM_RAID |
| 359 | tristate "RAID 1/4/5/6/10 target" |
| 360 | depends on BLK_DEV_DM |
| 361 | select MD_RAID0 |
| 362 | select MD_RAID1 |
| 363 | select MD_RAID10 |
| 364 | select MD_RAID456 |
| 365 | select BLK_DEV_MD |
| 366 | ---help--- |
| 367 | A dm target that supports RAID1, RAID10, RAID4, RAID5 and RAID6 mappings |
| 368 | |
| 369 | A RAID-5 set of N drives with a capacity of C MB per drive provides |
| 370 | the capacity of C * (N - 1) MB, and protects against a failure |
| 371 | of a single drive. For a given sector (row) number, (N - 1) drives |
| 372 | contain data sectors, and one drive contains the parity protection. |
| 373 | For a RAID-4 set, the parity blocks are present on a single drive, |
| 374 | while a RAID-5 set distributes the parity across the drives in one |
| 375 | of the available parity distribution methods. |
| 376 | |
| 377 | A RAID-6 set of N drives with a capacity of C MB per drive |
| 378 | provides the capacity of C * (N - 2) MB, and protects |
| 379 | against a failure of any two drives. For a given sector |
| 380 | (row) number, (N - 2) drives contain data sectors, and two |
| 381 | drives contains two independent redundancy syndromes. Like |
| 382 | RAID-5, RAID-6 distributes the syndromes across the drives |
| 383 | in one of the available parity distribution methods. |
| 384 | |
| 385 | config DM_ZERO |
| 386 | tristate "Zero target" |
| 387 | depends on BLK_DEV_DM |
| 388 | ---help--- |
| 389 | A target that discards writes, and returns all zeroes for |
| 390 | reads. Useful in some recovery situations. |
| 391 | |
| 392 | config DM_MULTIPATH |
| 393 | tristate "Multipath target" |
| 394 | depends on BLK_DEV_DM |
| 395 | # nasty syntax but means make DM_MULTIPATH independent |
| 396 | # of SCSI_DH if the latter isn't defined but if |
| 397 | # it is, DM_MULTIPATH must depend on it. We get a build |
| 398 | # error if SCSI_DH=m and DM_MULTIPATH=y |
| 399 | depends on !SCSI_DH || SCSI |
| 400 | ---help--- |
| 401 | Allow volume managers to support multipath hardware. |
| 402 | |
| 403 | config DM_MULTIPATH_QL |
| 404 | tristate "I/O Path Selector based on the number of in-flight I/Os" |
| 405 | depends on DM_MULTIPATH |
| 406 | ---help--- |
| 407 | This path selector is a dynamic load balancer which selects |
| 408 | the path with the least number of in-flight I/Os. |
| 409 | |
| 410 | If unsure, say N. |
| 411 | |
| 412 | config DM_MULTIPATH_ST |
| 413 | tristate "I/O Path Selector based on the service time" |
| 414 | depends on DM_MULTIPATH |
| 415 | ---help--- |
| 416 | This path selector is a dynamic load balancer which selects |
| 417 | the path expected to complete the incoming I/O in the shortest |
| 418 | time. |
| 419 | |
| 420 | If unsure, say N. |
| 421 | |
| 422 | config DM_DELAY |
| 423 | tristate "I/O delaying target" |
| 424 | depends on BLK_DEV_DM |
| 425 | ---help--- |
| 426 | A target that delays reads and/or writes and can send |
| 427 | them to different devices. Useful for testing. |
| 428 | |
| 429 | If unsure, say N. |
| 430 | |
| 431 | config DM_UEVENT |
| 432 | bool "DM uevents" |
| 433 | depends on BLK_DEV_DM |
| 434 | ---help--- |
| 435 | Generate udev events for DM events. |
| 436 | |
| 437 | config DM_FLAKEY |
| 438 | tristate "Flakey target" |
| 439 | depends on BLK_DEV_DM |
| 440 | ---help--- |
| 441 | A target that intermittently fails I/O for debugging purposes. |
| 442 | |
| 443 | config DM_VERITY |
| 444 | tristate "Verity target support" |
| 445 | depends on BLK_DEV_DM |
| 446 | select CRYPTO |
| 447 | select CRYPTO_HASH |
| 448 | select DM_BUFIO |
| 449 | ---help--- |
| 450 | This device-mapper target creates a read-only device that |
| 451 | transparently validates the data on one underlying device against |
| 452 | a pre-generated tree of cryptographic checksums stored on a second |
| 453 | device. |
| 454 | |
| 455 | You'll need to activate the digests you're going to use in the |
| 456 | cryptoapi configuration. |
| 457 | |
| 458 | To compile this code as a module, choose M here: the module will |
| 459 | be called dm-verity. |
| 460 | |
| 461 | If unsure, say N. |
| 462 | |
| 463 | config DM_VERITY_FEC |
| 464 | bool "Verity forward error correction support" |
| 465 | depends on DM_VERITY |
| 466 | select REED_SOLOMON |
| 467 | select REED_SOLOMON_DEC8 |
| 468 | ---help--- |
| 469 | Add forward error correction support to dm-verity. This option |
| 470 | makes it possible to use pre-generated error correction data to |
| 471 | recover from corrupted blocks. |
| 472 | |
| 473 | If unsure, say N. |
| 474 | |
| 475 | config DM_SWITCH |
| 476 | tristate "Switch target support (EXPERIMENTAL)" |
| 477 | depends on BLK_DEV_DM |
| 478 | ---help--- |
| 479 | This device-mapper target creates a device that supports an arbitrary |
| 480 | mapping of fixed-size regions of I/O across a fixed set of paths. |
| 481 | The path used for any specific region can be switched dynamically |
| 482 | by sending the target a message. |
| 483 | |
| 484 | To compile this code as a module, choose M here: the module will |
| 485 | be called dm-switch. |
| 486 | |
| 487 | If unsure, say N. |
| 488 | |
| 489 | config DM_LOG_WRITES |
| 490 | tristate "Log writes target support" |
| 491 | depends on BLK_DEV_DM |
| 492 | ---help--- |
| 493 | This device-mapper target takes two devices, one device to use |
| 494 | normally, one to log all write operations done to the first device. |
| 495 | This is for use by file system developers wishing to verify that |
| 496 | their fs is writing a consistent file system at all times by allowing |
| 497 | them to replay the log in a variety of ways and to check the |
| 498 | contents. |
| 499 | |
| 500 | To compile this code as a module, choose M here: the module will |
| 501 | be called dm-log-writes. |
| 502 | |
| 503 | If unsure, say N. |
| 504 | |
| 505 | config DM_INTEGRITY |
| 506 | tristate "Integrity target support" |
| 507 | depends on BLK_DEV_DM |
| 508 | select BLK_DEV_INTEGRITY |
| 509 | select DM_BUFIO |
| 510 | select CRYPTO |
| 511 | select ASYNC_XOR |
| 512 | ---help--- |
| 513 | This device-mapper target emulates a block device that has |
| 514 | additional per-sector tags that can be used for storing |
| 515 | integrity information. |
| 516 | |
| 517 | This integrity target is used with the dm-crypt target to |
| 518 | provide authenticated disk encryption or it can be used |
| 519 | standalone. |
| 520 | |
| 521 | To compile this code as a module, choose M here: the module will |
| 522 | be called dm-integrity. |
| 523 | |
| 524 | config DM_ZONED |
| 525 | tristate "Drive-managed zoned block device target support" |
| 526 | depends on BLK_DEV_DM |
| 527 | depends on BLK_DEV_ZONED |
| 528 | ---help--- |
| 529 | This device-mapper target takes a host-managed or host-aware zoned |
| 530 | block device and exposes most of its capacity as a regular block |
| 531 | device (drive-managed zoned block device) without any write |
| 532 | constraints. This is mainly intended for use with file systems that |
| 533 | do not natively support zoned block devices but still want to |
| 534 | benefit from the increased capacity offered by SMR disks. Other uses |
| 535 | by applications using raw block devices (for example object stores) |
| 536 | are also possible. |
| 537 | |
| 538 | To compile this code as a module, choose M here: the module will |
| 539 | be called dm-zoned. |
| 540 | |
| 541 | If unsure, say N. |
| 542 | |
| 543 | config DM_VERITY_AVB |
| 544 | tristate "Support AVB specific verity error behavior" |
| 545 | depends on DM_VERITY |
| 546 | ---help--- |
| 547 | Enables Android Verified Boot platform-specific error |
| 548 | behavior. In particular, it will modify the vbmeta partition |
| 549 | specified on the kernel command-line when non-transient error |
| 550 | occurs (followed by a panic). |
| 551 | |
| 552 | config DM_ANDROID_VERITY |
| 553 | bool "Android verity target support" |
| 554 | depends on BLK_DEV_DM=y |
| 555 | depends on DM_VERITY=y |
| 556 | depends on X509_CERTIFICATE_PARSER |
| 557 | depends on SYSTEM_TRUSTED_KEYRING |
| 558 | depends on CRYPTO_RSA |
| 559 | depends on KEYS |
| 560 | depends on ASYMMETRIC_KEY_TYPE |
| 561 | depends on ASYMMETRIC_PUBLIC_KEY_SUBTYPE |
| 562 | ---help--- |
| 563 | This device-mapper target is virtually a VERITY target. This |
| 564 | target is setup by reading the metadata contents piggybacked |
| 565 | to the actual data blocks in the block device. The signature |
| 566 | of the metadata contents are verified against the key included |
| 567 | in the system keyring. Upon success, the underlying verity |
| 568 | target is setup. |
| 569 | |
| 570 | config DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED |
| 571 | bool "Verity will validate blocks at most once" |
| 572 | depends on DM_VERITY |
| 573 | ---help--- |
| 574 | Default enables at_most_once option for dm-verity |
| 575 | |
| 576 | Verify data blocks only the first time they are read from the |
| 577 | data device, rather than every time. This reduces the overhead |
| 578 | of dm-verity so that it can be used on systems that are memory |
| 579 | and/or CPU constrained. However, it provides a reduced level |
| 580 | of security because only offline tampering of the data device's |
| 581 | content will be detected, not online tampering. |
| 582 | |
| 583 | Hash blocks are still verified each time they are read from the |
| 584 | hash device, since verification of hash blocks is less performance |
| 585 | critical than data blocks, and a hash block will not be verified |
| 586 | any more after all the data blocks it covers have been verified anyway. |
| 587 | |
| 588 | If unsure, say N. |
| 589 | endif # MD |