2019-06-01 08:08:42 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2012 Red Hat, Inc.
|
|
|
|
*
|
|
|
|
* Author: Mikulas Patocka <mpatocka@redhat.com>
|
|
|
|
*
|
|
|
|
* Based on Chromium dm-verity driver (C) 2011 The Chromium OS Authors
|
|
|
|
*
|
|
|
|
* In the file "/sys/module/dm_verity/parameters/prefetch_cluster" you can set
|
|
|
|
* default prefetch value. Data are read in "prefetch_cluster" chunks from the
|
|
|
|
* hash device. Setting this greatly improves performance when data and hash
|
|
|
|
* are on the same disk on different partitions on devices with poor random
|
|
|
|
* access behavior.
|
|
|
|
*/
|
|
|
|
|
2015-12-03 21:01:51 +00:00
|
|
|
#include "dm-verity.h"
|
2015-12-03 14:26:30 +00:00
|
|
|
#include "dm-verity-fec.h"
|
2019-07-18 00:46:15 +00:00
|
|
|
#include "dm-verity-verify-sig.h"
|
2023-03-01 11:34:15 +00:00
|
|
|
#include "dm-audit.h"
|
2012-03-28 17:43:38 +00:00
|
|
|
#include <linux/module.h>
|
2015-03-18 15:52:14 +00:00
|
|
|
#include <linux/reboot.h>
|
2021-09-20 12:33:28 +00:00
|
|
|
#include <linux/scatterlist.h>
|
2022-06-27 15:35:24 +00:00
|
|
|
#include <linux/string.h>
|
2022-07-25 20:52:17 +00:00
|
|
|
#include <linux/jump_label.h>
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
#include <linux/security.h>
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
#define DM_MSG_PREFIX "verity"
|
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
#define DM_VERITY_ENV_LENGTH 42
|
|
|
|
#define DM_VERITY_ENV_VAR_NAME "DM_VERITY_ERR_BLOCK_NR"
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
#define DM_VERITY_DEFAULT_PREFETCH_SIZE 262144
|
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
#define DM_VERITY_MAX_CORRUPTED_ERRS 100
|
|
|
|
|
|
|
|
#define DM_VERITY_OPT_LOGGING "ignore_corruption"
|
|
|
|
#define DM_VERITY_OPT_RESTART "restart_on_corruption"
|
2020-06-18 06:56:50 +00:00
|
|
|
#define DM_VERITY_OPT_PANIC "panic_on_corruption"
|
2024-10-02 14:03:41 +00:00
|
|
|
#define DM_VERITY_OPT_ERROR_RESTART "restart_on_error"
|
|
|
|
#define DM_VERITY_OPT_ERROR_PANIC "panic_on_error"
|
2015-12-03 14:26:31 +00:00
|
|
|
#define DM_VERITY_OPT_IGN_ZEROES "ignore_zero_blocks"
|
2018-03-23 01:18:04 +00:00
|
|
|
#define DM_VERITY_OPT_AT_MOST_ONCE "check_at_most_once"
|
2022-07-22 09:38:23 +00:00
|
|
|
#define DM_VERITY_OPT_TASKLET_VERIFY "try_verify_in_tasklet"
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-10-02 14:03:41 +00:00
|
|
|
#define DM_VERITY_OPTS_MAX (5 + DM_VERITY_OPTS_FEC + \
|
2019-07-18 00:46:15 +00:00
|
|
|
DM_VERITY_ROOT_HASH_VERIFICATION_OPTS)
|
2015-11-05 02:02:32 +00:00
|
|
|
|
2023-01-25 20:14:58 +00:00
|
|
|
static unsigned int dm_verity_prefetch_cluster = DM_VERITY_DEFAULT_PREFETCH_SIZE;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2023-02-06 22:58:05 +00:00
|
|
|
module_param_named(prefetch_cluster, dm_verity_prefetch_cluster, uint, 0644);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
static DEFINE_STATIC_KEY_FALSE(use_bh_wq_enabled);
|
2022-07-25 20:52:17 +00:00
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
/* Is at least one dm-verity instance using ahash_tfm instead of shash_tfm? */
|
|
|
|
static DEFINE_STATIC_KEY_FALSE(ahash_enabled);
|
|
|
|
|
2013-03-20 17:21:25 +00:00
|
|
|
struct dm_verity_prefetch_work {
|
|
|
|
struct work_struct work;
|
|
|
|
struct dm_verity *v;
|
2024-01-24 05:35:55 +00:00
|
|
|
unsigned short ioprio;
|
2013-03-20 17:21:25 +00:00
|
|
|
sector_t block;
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int n_blocks;
|
2013-03-20 17:21:25 +00:00
|
|
|
};
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* Auxiliary structure appended to each dm-bufio buffer. If the value
|
|
|
|
* hash_verified is nonzero, hash of the block has been verified.
|
|
|
|
*
|
|
|
|
* The variable hash_verified is set to 0 when allocating the buffer, then
|
|
|
|
* it can be changed to 1 and it is never reset to 0 again.
|
|
|
|
*
|
|
|
|
* There is no lock around this value, a race condition can at worst cause
|
|
|
|
* that multiple processes verify the hash of the same buffer simultaneously
|
|
|
|
* and write 1 to hash_verified simultaneously.
|
|
|
|
* This condition is harmless, so we don't need locking.
|
|
|
|
*/
|
|
|
|
struct buffer_aux {
|
|
|
|
int hash_verified;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize struct buffer_aux for a freshly created buffer.
|
|
|
|
*/
|
|
|
|
static void dm_bufio_alloc_callback(struct dm_buffer *buf)
|
|
|
|
{
|
|
|
|
struct buffer_aux *aux = dm_bufio_get_aux_data(buf);
|
|
|
|
|
|
|
|
aux->hash_verified = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Translate input sector number to the sector number on the target device.
|
|
|
|
*/
|
|
|
|
static sector_t verity_map_sector(struct dm_verity *v, sector_t bi_sector)
|
|
|
|
{
|
|
|
|
return v->data_start + dm_target_offset(v->ti, bi_sector);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return hash position of a specified block at a specified tree level
|
|
|
|
* (0 is the lowest level).
|
|
|
|
* The lowest "hash_per_block_bits"-bits of the result denote hash position
|
|
|
|
* inside a hash block. The remaining bits denote location of the hash block.
|
|
|
|
*/
|
|
|
|
static sector_t verity_position_at_level(struct dm_verity *v, sector_t block,
|
|
|
|
int level)
|
|
|
|
{
|
|
|
|
return block >> (level * v->hash_per_block_bits);
|
|
|
|
}
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
static int verity_ahash_update(struct dm_verity *v, struct ahash_request *req,
|
2017-02-19 12:46:07 +00:00
|
|
|
const u8 *data, size_t len,
|
2017-10-18 07:00:45 +00:00
|
|
|
struct crypto_wait *wait)
|
2015-11-05 02:02:31 +00:00
|
|
|
{
|
2017-02-19 12:46:07 +00:00
|
|
|
struct scatterlist sg;
|
2015-11-05 02:02:31 +00:00
|
|
|
|
2018-08-22 16:45:51 +00:00
|
|
|
if (likely(!is_vmalloc_addr(data))) {
|
|
|
|
sg_init_one(&sg, data, len);
|
|
|
|
ahash_request_set_crypt(req, &sg, NULL, len);
|
|
|
|
return crypto_wait_req(crypto_ahash_update(req), wait);
|
|
|
|
}
|
2023-02-07 19:35:25 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
int r;
|
|
|
|
size_t this_step = min_t(size_t, len, PAGE_SIZE - offset_in_page(data));
|
|
|
|
|
|
|
|
flush_kernel_vmap_range((void *)data, this_step);
|
|
|
|
sg_init_table(&sg, 1);
|
|
|
|
sg_set_page(&sg, vmalloc_to_page(data), this_step, offset_in_page(data));
|
|
|
|
ahash_request_set_crypt(req, &sg, NULL, this_step);
|
|
|
|
r = crypto_wait_req(crypto_ahash_update(req), wait);
|
|
|
|
if (unlikely(r))
|
|
|
|
return r;
|
|
|
|
data += this_step;
|
|
|
|
len -= this_step;
|
|
|
|
} while (len);
|
|
|
|
|
|
|
|
return 0;
|
2017-02-19 12:46:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wrapper for crypto_ahash_init, which handles verity salting.
|
|
|
|
*/
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
static int verity_ahash_init(struct dm_verity *v, struct ahash_request *req,
|
dm-verity: don't use blocking calls from tasklets
The commit 5721d4e5a9cd enhanced dm-verity, so that it can verify blocks
from tasklets rather than from workqueues. This reportedly improves
performance significantly.
However, dm-verity was using the flag CRYPTO_TFM_REQ_MAY_SLEEP from
tasklets which resulted in warnings about sleeping function being called
from non-sleeping context.
BUG: sleeping function called from invalid context at crypto/internal.h:206
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G W 6.7.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
__might_resched+0x110/0x160
crypto_hash_walk_done+0x54/0xb0
shash_ahash_update+0x51/0x60
verity_hash_update.isra.0+0x4a/0x130 [dm_verity]
verity_verify_io+0x165/0x550 [dm_verity]
? free_unref_page+0xdf/0x170
? psi_group_change+0x113/0x390
verity_tasklet+0xd/0x70 [dm_verity]
tasklet_action_common.isra.0+0xb3/0xc0
__do_softirq+0xaf/0x1ec
? smpboot_thread_fn+0x1d/0x200
? sort_range+0x20/0x20
run_ksoftirqd+0x15/0x30
smpboot_thread_fn+0xed/0x200
kthread+0xdc/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x28/0x40
? kthread_complete_and_exit+0x20/0x20
ret_from_fork_asm+0x11/0x20
</TASK>
This commit fixes dm-verity so that it doesn't use the flags
CRYPTO_TFM_REQ_MAY_SLEEP and CRYPTO_TFM_REQ_MAY_BACKLOG from tasklets. The
crypto API would do GFP_ATOMIC allocation instead, it could return -ENOMEM
and we catch -ENOMEM in verity_tasklet and requeue the request to the
workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # v6.0+
Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-17 17:37:25 +00:00
|
|
|
struct crypto_wait *wait, bool may_sleep)
|
2017-02-19 12:46:07 +00:00
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
ahash_request_set_tfm(req, v->ahash_tfm);
|
dm-verity: don't use blocking calls from tasklets
The commit 5721d4e5a9cd enhanced dm-verity, so that it can verify blocks
from tasklets rather than from workqueues. This reportedly improves
performance significantly.
However, dm-verity was using the flag CRYPTO_TFM_REQ_MAY_SLEEP from
tasklets which resulted in warnings about sleeping function being called
from non-sleeping context.
BUG: sleeping function called from invalid context at crypto/internal.h:206
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G W 6.7.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
__might_resched+0x110/0x160
crypto_hash_walk_done+0x54/0xb0
shash_ahash_update+0x51/0x60
verity_hash_update.isra.0+0x4a/0x130 [dm_verity]
verity_verify_io+0x165/0x550 [dm_verity]
? free_unref_page+0xdf/0x170
? psi_group_change+0x113/0x390
verity_tasklet+0xd/0x70 [dm_verity]
tasklet_action_common.isra.0+0xb3/0xc0
__do_softirq+0xaf/0x1ec
? smpboot_thread_fn+0x1d/0x200
? sort_range+0x20/0x20
run_ksoftirqd+0x15/0x30
smpboot_thread_fn+0xed/0x200
kthread+0xdc/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x28/0x40
? kthread_complete_and_exit+0x20/0x20
ret_from_fork_asm+0x11/0x20
</TASK>
This commit fixes dm-verity so that it doesn't use the flags
CRYPTO_TFM_REQ_MAY_SLEEP and CRYPTO_TFM_REQ_MAY_BACKLOG from tasklets. The
crypto API would do GFP_ATOMIC allocation instead, it could return -ENOMEM
and we catch -ENOMEM in verity_tasklet and requeue the request to the
workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # v6.0+
Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-17 17:37:25 +00:00
|
|
|
ahash_request_set_callback(req,
|
|
|
|
may_sleep ? CRYPTO_TFM_REQ_MAY_SLEEP | CRYPTO_TFM_REQ_MAY_BACKLOG : 0,
|
|
|
|
crypto_req_done, (void *)wait);
|
2017-10-18 07:00:45 +00:00
|
|
|
crypto_init_wait(wait);
|
2017-02-19 12:46:07 +00:00
|
|
|
|
2017-10-18 07:00:45 +00:00
|
|
|
r = crypto_wait_req(crypto_ahash_init(req), wait);
|
2017-02-19 12:46:07 +00:00
|
|
|
|
|
|
|
if (unlikely(r < 0)) {
|
dm-verity: don't use blocking calls from tasklets
The commit 5721d4e5a9cd enhanced dm-verity, so that it can verify blocks
from tasklets rather than from workqueues. This reportedly improves
performance significantly.
However, dm-verity was using the flag CRYPTO_TFM_REQ_MAY_SLEEP from
tasklets which resulted in warnings about sleeping function being called
from non-sleeping context.
BUG: sleeping function called from invalid context at crypto/internal.h:206
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G W 6.7.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
__might_resched+0x110/0x160
crypto_hash_walk_done+0x54/0xb0
shash_ahash_update+0x51/0x60
verity_hash_update.isra.0+0x4a/0x130 [dm_verity]
verity_verify_io+0x165/0x550 [dm_verity]
? free_unref_page+0xdf/0x170
? psi_group_change+0x113/0x390
verity_tasklet+0xd/0x70 [dm_verity]
tasklet_action_common.isra.0+0xb3/0xc0
__do_softirq+0xaf/0x1ec
? smpboot_thread_fn+0x1d/0x200
? sort_range+0x20/0x20
run_ksoftirqd+0x15/0x30
smpboot_thread_fn+0xed/0x200
kthread+0xdc/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x28/0x40
? kthread_complete_and_exit+0x20/0x20
ret_from_fork_asm+0x11/0x20
</TASK>
This commit fixes dm-verity so that it doesn't use the flags
CRYPTO_TFM_REQ_MAY_SLEEP and CRYPTO_TFM_REQ_MAY_BACKLOG from tasklets. The
crypto API would do GFP_ATOMIC allocation instead, it could return -ENOMEM
and we catch -ENOMEM in verity_tasklet and requeue the request to the
workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # v6.0+
Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-17 17:37:25 +00:00
|
|
|
if (r != -ENOMEM)
|
|
|
|
DMERR("crypto_ahash_init failed: %d", r);
|
2017-02-19 12:46:07 +00:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2017-05-18 10:47:25 +00:00
|
|
|
if (likely(v->salt_size && (v->version >= 1)))
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
r = verity_ahash_update(v, req, v->salt, v->salt_size, wait);
|
2015-11-05 02:02:31 +00:00
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
static int verity_ahash_final(struct dm_verity *v, struct ahash_request *req,
|
|
|
|
u8 *digest, struct crypto_wait *wait)
|
2015-11-05 02:02:31 +00:00
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
2017-05-18 10:47:25 +00:00
|
|
|
if (unlikely(v->salt_size && (!v->version))) {
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
r = verity_ahash_update(v, req, v->salt, v->salt_size, wait);
|
2015-11-05 02:02:31 +00:00
|
|
|
|
|
|
|
if (r < 0) {
|
2023-02-06 22:42:32 +00:00
|
|
|
DMERR("%s failed updating salt: %d", __func__, r);
|
2017-02-19 12:46:07 +00:00
|
|
|
goto out;
|
2015-11-05 02:02:31 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-19 12:46:07 +00:00
|
|
|
ahash_request_set_crypt(req, NULL, digest, 0);
|
2017-10-18 07:00:45 +00:00
|
|
|
r = crypto_wait_req(crypto_ahash_final(req), wait);
|
2017-02-19 12:46:07 +00:00
|
|
|
out:
|
2015-11-05 02:02:31 +00:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
int verity_hash(struct dm_verity *v, struct dm_verity_io *io,
|
dm-verity: don't use blocking calls from tasklets
The commit 5721d4e5a9cd enhanced dm-verity, so that it can verify blocks
from tasklets rather than from workqueues. This reportedly improves
performance significantly.
However, dm-verity was using the flag CRYPTO_TFM_REQ_MAY_SLEEP from
tasklets which resulted in warnings about sleeping function being called
from non-sleeping context.
BUG: sleeping function called from invalid context at crypto/internal.h:206
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G W 6.7.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
__might_resched+0x110/0x160
crypto_hash_walk_done+0x54/0xb0
shash_ahash_update+0x51/0x60
verity_hash_update.isra.0+0x4a/0x130 [dm_verity]
verity_verify_io+0x165/0x550 [dm_verity]
? free_unref_page+0xdf/0x170
? psi_group_change+0x113/0x390
verity_tasklet+0xd/0x70 [dm_verity]
tasklet_action_common.isra.0+0xb3/0xc0
__do_softirq+0xaf/0x1ec
? smpboot_thread_fn+0x1d/0x200
? sort_range+0x20/0x20
run_ksoftirqd+0x15/0x30
smpboot_thread_fn+0xed/0x200
kthread+0xdc/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x28/0x40
? kthread_complete_and_exit+0x20/0x20
ret_from_fork_asm+0x11/0x20
</TASK>
This commit fixes dm-verity so that it doesn't use the flags
CRYPTO_TFM_REQ_MAY_SLEEP and CRYPTO_TFM_REQ_MAY_BACKLOG from tasklets. The
crypto API would do GFP_ATOMIC allocation instead, it could return -ENOMEM
and we catch -ENOMEM in verity_tasklet and requeue the request to the
workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # v6.0+
Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-17 17:37:25 +00:00
|
|
|
const u8 *data, size_t len, u8 *digest, bool may_sleep)
|
2015-11-05 02:02:31 +00:00
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
if (static_branch_unlikely(&ahash_enabled) && !v->shash_tfm) {
|
|
|
|
struct ahash_request *req = verity_io_hash_req(v, io);
|
|
|
|
struct crypto_wait wait;
|
2017-02-19 12:46:07 +00:00
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
r = verity_ahash_init(v, req, &wait, may_sleep) ?:
|
|
|
|
verity_ahash_update(v, req, data, len, &wait) ?:
|
|
|
|
verity_ahash_final(v, req, digest, &wait);
|
|
|
|
} else {
|
|
|
|
struct shash_desc *desc = verity_io_hash_req(v, io);
|
2015-11-05 02:02:31 +00:00
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
desc->tfm = v->shash_tfm;
|
|
|
|
r = crypto_shash_import(desc, v->initial_hashstate) ?:
|
|
|
|
crypto_shash_finup(desc, data, len, digest);
|
|
|
|
}
|
|
|
|
if (unlikely(r))
|
|
|
|
DMERR("Error hashing block: %d", r);
|
2017-02-19 12:46:07 +00:00
|
|
|
return r;
|
2015-11-05 02:02:31 +00:00
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
static void verity_hash_at_level(struct dm_verity *v, sector_t block, int level,
|
2023-01-25 20:14:58 +00:00
|
|
|
sector_t *hash_block, unsigned int *offset)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
sector_t position = verity_position_at_level(v, block, level);
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int idx;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
*hash_block = v->hash_level_block[level] + (position >> v->hash_per_block_bits);
|
|
|
|
|
|
|
|
if (!offset)
|
|
|
|
return;
|
|
|
|
|
|
|
|
idx = position & ((1 << v->hash_per_block_bits) - 1);
|
|
|
|
if (!v->version)
|
|
|
|
*offset = idx * v->digest_size;
|
|
|
|
else
|
|
|
|
*offset = idx << (v->hash_dev_block_bits - v->hash_per_block_bits);
|
|
|
|
}
|
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
/*
|
|
|
|
* Handle verification errors.
|
|
|
|
*/
|
|
|
|
static int verity_handle_err(struct dm_verity *v, enum verity_block_type type,
|
|
|
|
unsigned long long block)
|
|
|
|
{
|
|
|
|
char verity_env[DM_VERITY_ENV_LENGTH];
|
|
|
|
char *envp[] = { verity_env, NULL };
|
|
|
|
const char *type_str = "";
|
|
|
|
struct mapped_device *md = dm_table_get_md(v->ti->table);
|
|
|
|
|
|
|
|
/* Corruption should be visible in device status in all modes */
|
2022-07-22 09:38:23 +00:00
|
|
|
v->hash_failed = true;
|
2015-03-18 15:52:14 +00:00
|
|
|
|
|
|
|
if (v->corrupted_errs >= DM_VERITY_MAX_CORRUPTED_ERRS)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
v->corrupted_errs++;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case DM_VERITY_BLOCK_TYPE_DATA:
|
|
|
|
type_str = "data";
|
|
|
|
break;
|
|
|
|
case DM_VERITY_BLOCK_TYPE_METADATA:
|
|
|
|
type_str = "metadata";
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2019-06-20 11:00:19 +00:00
|
|
|
DMERR_LIMIT("%s: %s block %llu is corrupted", v->data_dev->name,
|
|
|
|
type_str, block);
|
2015-03-18 15:52:14 +00:00
|
|
|
|
2023-03-01 11:34:15 +00:00
|
|
|
if (v->corrupted_errs == DM_VERITY_MAX_CORRUPTED_ERRS) {
|
2015-03-18 15:52:14 +00:00
|
|
|
DMERR("%s: reached maximum errors", v->data_dev->name);
|
2023-03-01 11:34:15 +00:00
|
|
|
dm_audit_log_target(DM_MSG_PREFIX, "max-corrupted-errors", v->ti, 0);
|
|
|
|
}
|
2015-03-18 15:52:14 +00:00
|
|
|
|
|
|
|
snprintf(verity_env, DM_VERITY_ENV_LENGTH, "%s=%d,%llu",
|
|
|
|
DM_VERITY_ENV_VAR_NAME, type, block);
|
|
|
|
|
|
|
|
kobject_uevent_env(&disk_to_dev(dm_disk(md))->kobj, KOBJ_CHANGE, envp);
|
|
|
|
|
|
|
|
out:
|
|
|
|
if (v->mode == DM_VERITY_MODE_LOGGING)
|
|
|
|
return 0;
|
|
|
|
|
2024-10-02 13:56:18 +00:00
|
|
|
if (v->mode == DM_VERITY_MODE_RESTART)
|
|
|
|
kernel_restart("dm-verity device corrupted");
|
2015-03-18 15:52:14 +00:00
|
|
|
|
2020-06-18 06:56:50 +00:00
|
|
|
if (v->mode == DM_VERITY_MODE_PANIC)
|
|
|
|
panic("dm-verity device corrupted");
|
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* Verify hash of a metadata block pertaining to the specified data block
|
|
|
|
* ("block" argument) at a specified level ("level" argument).
|
|
|
|
*
|
2015-12-03 21:01:51 +00:00
|
|
|
* On successful return, verity_io_want_digest(v, io) contains the hash value
|
|
|
|
* for a lower tree level or for the data block (if we're at the lowest level).
|
2012-03-28 17:43:38 +00:00
|
|
|
*
|
|
|
|
* If "skip_unverified" is true, unverified buffer is skipped and 1 is returned.
|
|
|
|
* If "skip_unverified" is false, unverified buffer is hashed and verified
|
2015-12-03 21:01:51 +00:00
|
|
|
* against current value of verity_io_want_digest(v, io).
|
2012-03-28 17:43:38 +00:00
|
|
|
*/
|
2015-11-05 02:02:31 +00:00
|
|
|
static int verity_verify_level(struct dm_verity *v, struct dm_verity_io *io,
|
|
|
|
sector_t block, int level, bool skip_unverified,
|
|
|
|
u8 *want_digest)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_buffer *buf;
|
|
|
|
struct buffer_aux *aux;
|
|
|
|
u8 *data;
|
|
|
|
int r;
|
|
|
|
sector_t hash_block;
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int offset;
|
2024-01-24 05:35:55 +00:00
|
|
|
struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
verity_hash_at_level(v, block, level, &hash_block, &offset);
|
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
if (static_branch_unlikely(&use_bh_wq_enabled) && io->in_bh) {
|
2022-07-22 09:38:23 +00:00
|
|
|
data = dm_bufio_get(v->bufio, hash_block, &buf);
|
|
|
|
if (data == NULL) {
|
|
|
|
/*
|
|
|
|
* In tasklet and the hash was not in the bufio cache.
|
|
|
|
* Return early and resume execution from a work-queue
|
|
|
|
* to read the hash from disk.
|
|
|
|
*/
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
2024-01-24 05:35:55 +00:00
|
|
|
} else {
|
|
|
|
data = dm_bufio_read_with_ioprio(v->bufio, hash_block,
|
|
|
|
&buf, bio_prio(bio));
|
|
|
|
}
|
2022-07-22 09:38:23 +00:00
|
|
|
|
2015-08-10 06:12:26 +00:00
|
|
|
if (IS_ERR(data))
|
2012-03-28 17:43:38 +00:00
|
|
|
return PTR_ERR(data);
|
|
|
|
|
|
|
|
aux = dm_bufio_get_aux_data(buf);
|
|
|
|
|
|
|
|
if (!aux->hash_verified) {
|
|
|
|
if (skip_unverified) {
|
|
|
|
r = 1;
|
|
|
|
goto release_ret_r;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
r = verity_hash(v, io, data, 1 << v->hash_dev_block_bits,
|
2024-01-30 09:11:55 +00:00
|
|
|
verity_io_real_digest(v, io), !io->in_bh);
|
2015-11-05 02:02:31 +00:00
|
|
|
if (unlikely(r < 0))
|
2012-03-28 17:43:38 +00:00
|
|
|
goto release_ret_r;
|
|
|
|
|
2015-12-03 21:01:51 +00:00
|
|
|
if (likely(memcmp(verity_io_real_digest(v, io), want_digest,
|
2015-11-05 02:02:31 +00:00
|
|
|
v->digest_size) == 0))
|
|
|
|
aux->hash_verified = 1;
|
2024-01-30 09:11:55 +00:00
|
|
|
else if (static_branch_unlikely(&use_bh_wq_enabled) && io->in_bh) {
|
2022-07-22 09:38:23 +00:00
|
|
|
/*
|
|
|
|
* Error handling code (FEC included) cannot be run in a
|
|
|
|
* tasklet since it may sleep, so fallback to work-queue.
|
|
|
|
*/
|
|
|
|
r = -EAGAIN;
|
|
|
|
goto release_ret_r;
|
2023-01-30 21:13:54 +00:00
|
|
|
} else if (verity_fec_decode(v, io, DM_VERITY_BLOCK_TYPE_METADATA,
|
2024-07-02 14:40:20 +00:00
|
|
|
hash_block, data) == 0)
|
2015-12-03 14:26:30 +00:00
|
|
|
aux->hash_verified = 1;
|
2015-11-05 02:02:31 +00:00
|
|
|
else if (verity_handle_err(v,
|
|
|
|
DM_VERITY_BLOCK_TYPE_METADATA,
|
|
|
|
hash_block)) {
|
2024-10-29 11:17:13 +00:00
|
|
|
struct bio *bio;
|
|
|
|
io->had_mismatch = true;
|
|
|
|
bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
|
2023-03-01 11:34:15 +00:00
|
|
|
dm_audit_log_bio(DM_MSG_PREFIX, "verify-metadata", bio,
|
|
|
|
block, 0);
|
2015-11-05 02:02:31 +00:00
|
|
|
r = -EIO;
|
2012-03-28 17:43:38 +00:00
|
|
|
goto release_ret_r;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
data += offset;
|
2015-11-05 02:02:31 +00:00
|
|
|
memcpy(want_digest, data, v->digest_size);
|
|
|
|
r = 0;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
release_ret_r:
|
|
|
|
dm_bufio_release(buf);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-11-05 02:02:31 +00:00
|
|
|
/*
|
|
|
|
* Find a hash for a given block, write it to digest and verify the integrity
|
|
|
|
* of the hash tree if necessary.
|
|
|
|
*/
|
2015-12-03 21:01:51 +00:00
|
|
|
int verity_hash_for_block(struct dm_verity *v, struct dm_verity_io *io,
|
2015-12-03 14:26:31 +00:00
|
|
|
sector_t block, u8 *digest, bool *is_zero)
|
2015-11-05 02:02:31 +00:00
|
|
|
{
|
2015-12-03 14:26:31 +00:00
|
|
|
int r = 0, i;
|
2015-11-05 02:02:31 +00:00
|
|
|
|
|
|
|
if (likely(v->levels)) {
|
|
|
|
/*
|
|
|
|
* First, we try to get the requested hash for
|
|
|
|
* the current block. If the hash block itself is
|
|
|
|
* verified, zero is returned. If it isn't, this
|
|
|
|
* function returns 1 and we fall back to whole
|
|
|
|
* chain verification.
|
|
|
|
*/
|
|
|
|
r = verity_verify_level(v, io, block, 0, true, digest);
|
|
|
|
if (likely(r <= 0))
|
2015-12-03 14:26:31 +00:00
|
|
|
goto out;
|
2015-11-05 02:02:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(digest, v->root_digest, v->digest_size);
|
|
|
|
|
|
|
|
for (i = v->levels - 1; i >= 0; i--) {
|
|
|
|
r = verity_verify_level(v, io, block, i, false, digest);
|
|
|
|
if (unlikely(r))
|
2015-12-03 14:26:31 +00:00
|
|
|
goto out;
|
2015-11-05 02:02:31 +00:00
|
|
|
}
|
2015-12-03 14:26:31 +00:00
|
|
|
out:
|
|
|
|
if (!r && v->zero_digest)
|
|
|
|
*is_zero = !memcmp(v->zero_digest, digest, v->digest_size);
|
|
|
|
else
|
|
|
|
*is_zero = false;
|
2015-11-05 02:02:31 +00:00
|
|
|
|
2015-12-03 14:26:31 +00:00
|
|
|
return r;
|
2015-11-05 02:02:31 +00:00
|
|
|
}
|
|
|
|
|
2024-02-24 13:48:03 +00:00
|
|
|
static noinline int verity_recheck(struct dm_verity *v, struct dm_verity_io *io,
|
2024-07-02 14:40:20 +00:00
|
|
|
sector_t cur_block, u8 *dest)
|
2024-02-19 20:28:09 +00:00
|
|
|
{
|
|
|
|
struct page *page;
|
|
|
|
void *buffer;
|
|
|
|
int r;
|
|
|
|
struct dm_io_request io_req;
|
|
|
|
struct dm_io_region io_loc;
|
|
|
|
|
|
|
|
page = mempool_alloc(&v->recheck_pool, GFP_NOIO);
|
|
|
|
buffer = page_to_virt(page);
|
|
|
|
|
|
|
|
io_req.bi_opf = REQ_OP_READ;
|
|
|
|
io_req.mem.type = DM_IO_KMEM;
|
|
|
|
io_req.mem.ptr.addr = buffer;
|
|
|
|
io_req.notify.fn = NULL;
|
|
|
|
io_req.client = v->io;
|
|
|
|
io_loc.bdev = v->data_dev->bdev;
|
|
|
|
io_loc.sector = cur_block << (v->data_dev_block_bits - SECTOR_SHIFT);
|
|
|
|
io_loc.count = 1 << (v->data_dev_block_bits - SECTOR_SHIFT);
|
2024-01-24 05:35:53 +00:00
|
|
|
r = dm_io(&io_req, 1, &io_loc, NULL, IOPRIO_DEFAULT);
|
2024-02-19 20:28:09 +00:00
|
|
|
if (unlikely(r))
|
|
|
|
goto free_ret;
|
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
r = verity_hash(v, io, buffer, 1 << v->data_dev_block_bits,
|
2024-02-19 20:28:09 +00:00
|
|
|
verity_io_real_digest(v, io), true);
|
|
|
|
if (unlikely(r))
|
|
|
|
goto free_ret;
|
|
|
|
|
|
|
|
if (memcmp(verity_io_real_digest(v, io),
|
|
|
|
verity_io_want_digest(v, io), v->digest_size)) {
|
|
|
|
r = -EIO;
|
|
|
|
goto free_ret;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:40:20 +00:00
|
|
|
memcpy(dest, buffer, 1 << v->data_dev_block_bits);
|
2024-02-19 20:28:09 +00:00
|
|
|
r = 0;
|
|
|
|
free_ret:
|
|
|
|
mempool_free(page, &v->recheck_pool);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:38:21 +00:00
|
|
|
static int verity_handle_data_hash_mismatch(struct dm_verity *v,
|
|
|
|
struct dm_verity_io *io,
|
|
|
|
struct bio *bio, sector_t blkno,
|
2024-07-02 14:40:20 +00:00
|
|
|
u8 *data)
|
2024-07-02 14:38:21 +00:00
|
|
|
{
|
|
|
|
if (static_branch_unlikely(&use_bh_wq_enabled) && io->in_bh) {
|
|
|
|
/*
|
|
|
|
* Error handling code (FEC included) cannot be run in the
|
|
|
|
* BH workqueue, so fallback to a standard workqueue.
|
|
|
|
*/
|
|
|
|
return -EAGAIN;
|
|
|
|
}
|
2024-07-02 14:40:20 +00:00
|
|
|
if (verity_recheck(v, io, blkno, data) == 0) {
|
2024-07-02 14:38:21 +00:00
|
|
|
if (v->validated_blocks)
|
|
|
|
set_bit(blkno, v->validated_blocks);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
#if defined(CONFIG_DM_VERITY_FEC)
|
|
|
|
if (verity_fec_decode(v, io, DM_VERITY_BLOCK_TYPE_DATA, blkno,
|
2024-07-02 14:40:20 +00:00
|
|
|
data) == 0)
|
2024-07-02 14:38:21 +00:00
|
|
|
return 0;
|
|
|
|
#endif
|
|
|
|
if (bio->bi_status)
|
|
|
|
return -EIO; /* Error correction failed; Just return error */
|
|
|
|
|
|
|
|
if (verity_handle_err(v, DM_VERITY_BLOCK_TYPE_DATA, blkno)) {
|
2024-10-29 11:17:13 +00:00
|
|
|
io->had_mismatch = true;
|
2024-07-02 14:38:21 +00:00
|
|
|
dm_audit_log_bio(DM_MSG_PREFIX, "verify-data", bio, blkno, 0);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* Verify one "dm_verity_io" structure.
|
|
|
|
*/
|
|
|
|
static int verity_verify_io(struct dm_verity_io *io)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = io->v;
|
2024-07-02 14:40:20 +00:00
|
|
|
const unsigned int block_size = 1 << v->data_dev_block_bits;
|
2022-08-04 17:37:53 +00:00
|
|
|
struct bvec_iter iter_copy;
|
|
|
|
struct bvec_iter *iter;
|
2021-09-13 09:26:42 +00:00
|
|
|
struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
|
2022-07-22 09:38:23 +00:00
|
|
|
unsigned int b;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
if (static_branch_unlikely(&use_bh_wq_enabled) && io->in_bh) {
|
2022-08-04 17:37:53 +00:00
|
|
|
/*
|
|
|
|
* Copy the iterator in case we need to restart
|
|
|
|
* verification in a work-queue.
|
|
|
|
*/
|
|
|
|
iter_copy = io->iter;
|
|
|
|
iter = &iter_copy;
|
|
|
|
} else
|
|
|
|
iter = &io->iter;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-07-02 14:40:20 +00:00
|
|
|
for (b = 0; b < io->n_blocks;
|
|
|
|
b++, bio_advance_iter(bio, iter, block_size)) {
|
2012-03-28 17:43:38 +00:00
|
|
|
int r;
|
2018-03-23 01:18:04 +00:00
|
|
|
sector_t cur_block = io->block + b;
|
2024-07-02 14:40:20 +00:00
|
|
|
bool is_zero;
|
|
|
|
struct bio_vec bv;
|
|
|
|
void *data;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
dm verity: fix error handling for check_at_most_once on FEC
In verity_end_io(), if bi_status is not BLK_STS_OK, it can be return
directly. But if FEC configured, it is desired to correct the data page
through verity_verify_io. And the return value will be converted to
blk_status and passed to verity_finish_io().
BTW, when a bit is set in v->validated_blocks, verity_verify_io() skips
verification regardless of I/O error for the corresponding bio. In this
case, the I/O error could not be returned properly, and as a result,
there is a problem that abnormal data could be read for the
corresponding block.
To fix this problem, when an I/O error occurs, do not skip verification
even if the bit related is set in v->validated_blocks.
Fixes: 843f38d382b1 ("dm verity: add 'check_at_most_once' option to only validate hashes once")
Cc: stable@vger.kernel.org
Reviewed-by: Sungjong Seo <sj1557.seo@samsung.com>
Signed-off-by: Yeongjin Gil <youngjin.gil@samsung.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-03-20 06:59:32 +00:00
|
|
|
if (v->validated_blocks && bio->bi_status == BLK_STS_OK &&
|
2024-07-02 14:40:20 +00:00
|
|
|
likely(test_bit(cur_block, v->validated_blocks)))
|
2018-03-23 01:18:04 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
r = verity_hash_for_block(v, io, cur_block,
|
2015-12-03 14:26:31 +00:00
|
|
|
verity_io_want_digest(v, io),
|
|
|
|
&is_zero);
|
2015-11-05 02:02:31 +00:00
|
|
|
if (unlikely(r < 0))
|
|
|
|
return r;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-07-02 14:40:20 +00:00
|
|
|
bv = bio_iter_iovec(bio, *iter);
|
|
|
|
if (unlikely(bv.bv_len < block_size)) {
|
|
|
|
/*
|
|
|
|
* Data block spans pages. This should not happen,
|
|
|
|
* since dm-verity sets dma_alignment to the data block
|
|
|
|
* size minus 1, and dm-verity also doesn't allow the
|
|
|
|
* data block size to be greater than PAGE_SIZE.
|
|
|
|
*/
|
|
|
|
DMERR_LIMIT("unaligned io (data block spans pages)");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
data = bvec_kmap_local(&bv);
|
|
|
|
|
2015-12-03 14:26:31 +00:00
|
|
|
if (is_zero) {
|
|
|
|
/*
|
|
|
|
* If we expect a zero block, don't validate, just
|
|
|
|
* return zeros.
|
|
|
|
*/
|
2024-07-02 14:40:20 +00:00
|
|
|
memset(data, 0, block_size);
|
|
|
|
kunmap_local(data);
|
2015-12-03 14:26:31 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
r = verity_hash(v, io, data, block_size,
|
2024-07-02 14:40:20 +00:00
|
|
|
verity_io_real_digest(v, io), !io->in_bh);
|
|
|
|
if (unlikely(r < 0)) {
|
|
|
|
kunmap_local(data);
|
2012-03-28 17:43:38 +00:00
|
|
|
return r;
|
2024-07-02 14:40:20 +00:00
|
|
|
}
|
2015-11-05 02:02:31 +00:00
|
|
|
|
2015-12-03 21:01:51 +00:00
|
|
|
if (likely(memcmp(verity_io_real_digest(v, io),
|
2018-03-23 01:18:04 +00:00
|
|
|
verity_io_want_digest(v, io), v->digest_size) == 0)) {
|
|
|
|
if (v->validated_blocks)
|
|
|
|
set_bit(cur_block, v->validated_blocks);
|
2024-07-02 14:40:20 +00:00
|
|
|
kunmap_local(data);
|
2015-11-05 02:02:31 +00:00
|
|
|
continue;
|
2021-09-13 09:26:42 +00:00
|
|
|
}
|
2024-07-02 14:38:21 +00:00
|
|
|
r = verity_handle_data_hash_mismatch(v, io, bio, cur_block,
|
2024-07-02 14:40:20 +00:00
|
|
|
data);
|
|
|
|
kunmap_local(data);
|
2024-07-02 14:38:21 +00:00
|
|
|
if (unlikely(r))
|
|
|
|
return r;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-12-03 00:46:59 +00:00
|
|
|
/*
|
|
|
|
* Skip verity work in response to I/O error when system is shutting down.
|
|
|
|
*/
|
|
|
|
static inline bool verity_is_system_shutting_down(void)
|
|
|
|
{
|
|
|
|
return system_state == SYSTEM_HALT || system_state == SYSTEM_POWER_OFF
|
|
|
|
|| system_state == SYSTEM_RESTART;
|
|
|
|
}
|
|
|
|
|
2024-10-02 14:03:41 +00:00
|
|
|
static void restart_io_error(struct work_struct *w)
|
|
|
|
{
|
|
|
|
kernel_restart("dm-verity device has I/O error");
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* End one "io" structure with a given error.
|
|
|
|
*/
|
2017-06-03 07:38:06 +00:00
|
|
|
static void verity_finish_io(struct dm_verity_io *io, blk_status_t status)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity *v = io->v;
|
2016-01-31 18:28:26 +00:00
|
|
|
struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
bio->bi_end_io = io->orig_bi_end_io;
|
2017-06-03 07:38:06 +00:00
|
|
|
bio->bi_status = status;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
if (!static_branch_unlikely(&use_bh_wq_enabled) || !io->in_bh)
|
2022-07-22 09:38:23 +00:00
|
|
|
verity_fec_finish_io(io);
|
2015-12-03 14:26:30 +00:00
|
|
|
|
2024-10-02 14:03:41 +00:00
|
|
|
if (unlikely(status != BLK_STS_OK) &&
|
|
|
|
unlikely(!(bio->bi_opf & REQ_RAHEAD)) &&
|
2024-10-29 11:17:13 +00:00
|
|
|
!io->had_mismatch &&
|
2024-10-02 14:03:41 +00:00
|
|
|
!verity_is_system_shutting_down()) {
|
|
|
|
if (v->error_mode == DM_VERITY_MODE_PANIC) {
|
|
|
|
panic("dm-verity device has I/O error");
|
|
|
|
}
|
|
|
|
if (v->error_mode == DM_VERITY_MODE_RESTART) {
|
|
|
|
static DECLARE_WORK(restart_work, restart_io_error);
|
|
|
|
queue_work(v->verify_wq, &restart_work);
|
|
|
|
/*
|
|
|
|
* We deliberately don't call bio_endio here, because
|
|
|
|
* the machine will be restarted anyway.
|
|
|
|
*/
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-07-20 13:29:37 +00:00
|
|
|
bio_endio(bio);
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void verity_work(struct work_struct *w)
|
|
|
|
{
|
|
|
|
struct dm_verity_io *io = container_of(w, struct dm_verity_io, work);
|
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
io->in_bh = false;
|
2022-07-22 09:38:23 +00:00
|
|
|
|
2017-06-03 07:38:06 +00:00
|
|
|
verity_finish_io(io, errno_to_blk_status(verity_verify_io(io)));
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
static void verity_bh_work(struct work_struct *w)
|
|
|
|
{
|
|
|
|
struct dm_verity_io *io = container_of(w, struct dm_verity_io, bh_work);
|
|
|
|
int err;
|
|
|
|
|
|
|
|
io->in_bh = true;
|
|
|
|
err = verity_verify_io(io);
|
|
|
|
if (err == -EAGAIN || err == -ENOMEM) {
|
|
|
|
/* fallback to retrying with work-queue */
|
|
|
|
INIT_WORK(&io->work, verity_work);
|
|
|
|
queue_work(io->v->verify_wq, &io->work);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
verity_finish_io(io, errno_to_blk_status(err));
|
|
|
|
}
|
|
|
|
|
2015-07-20 13:29:37 +00:00
|
|
|
static void verity_end_io(struct bio *bio)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity_io *io = bio->bi_private;
|
|
|
|
|
2020-12-03 00:46:59 +00:00
|
|
|
if (bio->bi_status &&
|
dm verity: don't perform FEC for failed readahead IO
We found an issue under Android OTA scenario that many BIOs have to do
FEC where the data under dm-verity is 100% complete and no corruption.
Android OTA has many dm-block layers, from upper to lower:
dm-verity
dm-snapshot
dm-origin & dm-cow
dm-linear
ufs
DM tables have to change 2 times during Android OTA merging process.
When doing table change, the dm-snapshot will be suspended for a while.
During this interval, many readahead IOs are submitted to dm_verity
from filesystem. Then the kverity works are busy doing FEC process
which cost too much time to finish dm-verity IO. This causes needless
delay which feels like system is hung.
After adding debugging it was found that each readahead IO needed
around 10s to finish when this situation occurred. This is due to IO
amplification:
dm-snapshot suspend
erofs_readahead // 300+ io is submitted
dm_submit_bio (dm_verity)
dm_submit_bio (dm_snapshot)
bio return EIO
bio got nothing, it's empty
verity_end_io
verity_verify_io
forloop range(0, io->n_blocks) // each io->nblocks ~= 20
verity_fec_decode
fec_decode_rsb
fec_read_bufs
forloop range(0, v->fec->rsn) // v->fec->rsn = 253
new_read
submit_bio (dm_snapshot)
end loop
end loop
dm-snapshot resume
Readahead BIOs get nothing while dm-snapshot is suspended, so all of
them will cause verity's FEC.
Each readahead BIO needs to verify ~20 (io->nblocks) blocks.
Each block needs to do FEC, and every block needs to do 253
(v->fec->rsn) reads.
So during the suspend interval(~200ms), 300 readahead BIOs trigger
~1518000 (300*20*253) IOs to dm-snapshot.
As readahead IO is not required by userspace, and to fix this issue,
it is best to pass readahead errors to upper layer to handle it.
Cc: stable@vger.kernel.org
Fixes: a739ff3f543a ("dm verity: add support for forward error correction")
Signed-off-by: Wu Bo <bo.wu@vivo.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-22 03:51:50 +00:00
|
|
|
(!verity_fec_is_enabled(io->v) ||
|
|
|
|
verity_is_system_shutting_down() ||
|
|
|
|
(bio->bi_opf & REQ_RAHEAD))) {
|
2017-06-03 07:38:06 +00:00
|
|
|
verity_finish_io(io, bio->bi_status);
|
2012-03-28 17:43:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
if (static_branch_unlikely(&use_bh_wq_enabled) && io->v->use_bh_wq) {
|
|
|
|
INIT_WORK(&io->bh_work, verity_bh_work);
|
|
|
|
queue_work(system_bh_wq, &io->bh_work);
|
|
|
|
} else {
|
|
|
|
INIT_WORK(&io->work, verity_work);
|
|
|
|
queue_work(io->v->verify_wq, &io->work);
|
|
|
|
}
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prefetch buffers for the specified io.
|
|
|
|
* The root buffer is not prefetched, it is assumed that it will be cached
|
|
|
|
* all the time.
|
|
|
|
*/
|
2013-03-20 17:21:25 +00:00
|
|
|
static void verity_prefetch_io(struct work_struct *work)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
2013-03-20 17:21:25 +00:00
|
|
|
struct dm_verity_prefetch_work *pw =
|
|
|
|
container_of(work, struct dm_verity_prefetch_work, work);
|
|
|
|
struct dm_verity *v = pw->v;
|
2012-03-28 17:43:38 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = v->levels - 2; i >= 0; i--) {
|
|
|
|
sector_t hash_block_start;
|
|
|
|
sector_t hash_block_end;
|
2023-02-01 22:42:29 +00:00
|
|
|
|
2013-03-20 17:21:25 +00:00
|
|
|
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);
|
2023-02-01 22:42:29 +00:00
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
if (!i) {
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int cluster = READ_ONCE(dm_verity_prefetch_cluster);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
cluster >>= v->data_dev_block_bits;
|
|
|
|
if (unlikely(!cluster))
|
|
|
|
goto no_prefetch_cluster;
|
|
|
|
|
|
|
|
if (unlikely(cluster & (cluster - 1)))
|
2013-07-10 22:41:17 +00:00
|
|
|
cluster = 1 << __fls(cluster);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
hash_block_start &= ~(sector_t)(cluster - 1);
|
|
|
|
hash_block_end |= cluster - 1;
|
|
|
|
if (unlikely(hash_block_end >= v->hash_blocks))
|
|
|
|
hash_block_end = v->hash_blocks - 1;
|
|
|
|
}
|
|
|
|
no_prefetch_cluster:
|
2024-01-24 05:35:55 +00:00
|
|
|
dm_bufio_prefetch_with_ioprio(v->bufio, hash_block_start,
|
|
|
|
hash_block_end - hash_block_start + 1,
|
|
|
|
pw->ioprio);
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
2013-03-20 17:21:25 +00:00
|
|
|
|
|
|
|
kfree(pw);
|
|
|
|
}
|
|
|
|
|
2024-01-24 05:35:55 +00:00
|
|
|
static void verity_submit_prefetch(struct dm_verity *v, struct dm_verity_io *io,
|
|
|
|
unsigned short ioprio)
|
2013-03-20 17:21:25 +00:00
|
|
|
{
|
2020-01-07 04:34:24 +00:00
|
|
|
sector_t block = io->block;
|
|
|
|
unsigned int n_blocks = io->n_blocks;
|
2013-03-20 17:21:25 +00:00
|
|
|
struct dm_verity_prefetch_work *pw;
|
|
|
|
|
2020-01-07 04:34:24 +00:00
|
|
|
if (v->validated_blocks) {
|
|
|
|
while (n_blocks && test_bit(block, v->validated_blocks)) {
|
|
|
|
block++;
|
|
|
|
n_blocks--;
|
|
|
|
}
|
|
|
|
while (n_blocks && test_bit(block + n_blocks - 1,
|
|
|
|
v->validated_blocks))
|
|
|
|
n_blocks--;
|
|
|
|
if (!n_blocks)
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2013-03-20 17:21:25 +00:00
|
|
|
pw = kmalloc(sizeof(struct dm_verity_prefetch_work),
|
|
|
|
GFP_NOIO | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN);
|
|
|
|
|
|
|
|
if (!pw)
|
|
|
|
return;
|
|
|
|
|
|
|
|
INIT_WORK(&pw->work, verity_prefetch_io);
|
|
|
|
pw->v = v;
|
2020-01-07 04:34:24 +00:00
|
|
|
pw->block = block;
|
|
|
|
pw->n_blocks = n_blocks;
|
2024-01-24 05:35:55 +00:00
|
|
|
pw->ioprio = ioprio;
|
2013-03-20 17:21:25 +00:00
|
|
|
queue_work(v->verify_wq, &pw->work);
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Bio map function. It allocates dm_verity_io structure and bio vector and
|
|
|
|
* fills them. Then it issues prefetches and the I/O.
|
|
|
|
*/
|
2012-12-21 20:23:41 +00:00
|
|
|
static int verity_map(struct dm_target *ti, struct bio *bio)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
struct dm_verity_io *io;
|
|
|
|
|
2017-08-23 17:10:32 +00:00
|
|
|
bio_set_dev(bio, v->data_dev->bdev);
|
2013-10-11 22:44:27 +00:00
|
|
|
bio->bi_iter.bi_sector = verity_map_sector(v, bio->bi_iter.bi_sector);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2023-01-25 20:14:58 +00:00
|
|
|
if (((unsigned int)bio->bi_iter.bi_sector | bio_sectors(bio)) &
|
2012-03-28 17:43:38 +00:00
|
|
|
((1 << (v->data_dev_block_bits - SECTOR_SHIFT)) - 1)) {
|
|
|
|
DMERR_LIMIT("unaligned io");
|
2017-06-03 07:38:02 +00:00
|
|
|
return DM_MAPIO_KILL;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
2012-09-25 22:05:12 +00:00
|
|
|
if (bio_end_sector(bio) >>
|
2012-03-28 17:43:38 +00:00
|
|
|
(v->data_dev_block_bits - SECTOR_SHIFT) > v->data_blocks) {
|
|
|
|
DMERR_LIMIT("io out of range");
|
2017-06-03 07:38:02 +00:00
|
|
|
return DM_MAPIO_KILL;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (bio_data_dir(bio) == WRITE)
|
2017-06-03 07:38:02 +00:00
|
|
|
return DM_MAPIO_KILL;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2016-01-31 18:28:26 +00:00
|
|
|
io = dm_per_bio_data(bio, ti->per_io_data_size);
|
2012-03-28 17:43:38 +00:00
|
|
|
io->v = v;
|
|
|
|
io->orig_bi_end_io = bio->bi_end_io;
|
2013-10-11 22:44:27 +00:00
|
|
|
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;
|
2024-10-29 11:17:13 +00:00
|
|
|
io->had_mismatch = false;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
bio->bi_end_io = verity_end_io;
|
|
|
|
bio->bi_private = io;
|
2013-10-11 22:45:43 +00:00
|
|
|
io->iter = bio->bi_iter;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2023-11-22 03:51:49 +00:00
|
|
|
verity_fec_init_io(io);
|
|
|
|
|
2024-01-24 05:35:55 +00:00
|
|
|
verity_submit_prefetch(v, io, bio_prio(bio));
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2020-07-01 08:59:44 +00:00
|
|
|
submit_bio_noacct(bio);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
return DM_MAPIO_SUBMITTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Status: V (valid) or C (corruption found)
|
|
|
|
*/
|
2013-03-01 22:45:44 +00:00
|
|
|
static void verity_status(struct dm_target *ti, status_type_t type,
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int status_flags, char *result, unsigned int maxlen)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int args = 0;
|
|
|
|
unsigned int sz = 0;
|
|
|
|
unsigned int x;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case STATUSTYPE_INFO:
|
|
|
|
DMEMIT("%c", v->hash_failed ? 'C' : 'V');
|
|
|
|
break;
|
|
|
|
case STATUSTYPE_TABLE:
|
|
|
|
DMEMIT("%u %s %s %u %u %llu %llu %s ",
|
|
|
|
v->version,
|
|
|
|
v->data_dev->name,
|
|
|
|
v->hash_dev->name,
|
|
|
|
1 << v->data_dev_block_bits,
|
|
|
|
1 << v->hash_dev_block_bits,
|
|
|
|
(unsigned long long)v->data_blocks,
|
|
|
|
(unsigned long long)v->hash_start,
|
|
|
|
v->alg_name
|
|
|
|
);
|
|
|
|
for (x = 0; x < v->digest_size; x++)
|
|
|
|
DMEMIT("%02x", v->root_digest[x]);
|
|
|
|
DMEMIT(" ");
|
|
|
|
if (!v->salt_size)
|
|
|
|
DMEMIT("-");
|
|
|
|
else
|
|
|
|
for (x = 0; x < v->salt_size; x++)
|
|
|
|
DMEMIT("%02x", v->salt[x]);
|
2015-12-03 14:26:30 +00:00
|
|
|
if (v->mode != DM_VERITY_MODE_EIO)
|
|
|
|
args++;
|
2024-10-02 14:03:41 +00:00
|
|
|
if (v->error_mode != DM_VERITY_MODE_EIO)
|
|
|
|
args++;
|
2015-12-03 14:26:30 +00:00
|
|
|
if (verity_fec_is_enabled(v))
|
|
|
|
args += DM_VERITY_OPTS_FEC;
|
2015-12-03 14:26:31 +00:00
|
|
|
if (v->zero_digest)
|
|
|
|
args++;
|
2018-03-23 01:18:04 +00:00
|
|
|
if (v->validated_blocks)
|
|
|
|
args++;
|
2024-01-30 09:11:55 +00:00
|
|
|
if (v->use_bh_wq)
|
2022-07-22 09:38:23 +00:00
|
|
|
args++;
|
2019-07-18 00:46:15 +00:00
|
|
|
if (v->signature_key_desc)
|
|
|
|
args += DM_VERITY_ROOT_HASH_VERIFICATION_OPTS;
|
2015-12-03 14:26:30 +00:00
|
|
|
if (!args)
|
|
|
|
return;
|
|
|
|
DMEMIT(" %u", args);
|
2015-03-18 15:52:14 +00:00
|
|
|
if (v->mode != DM_VERITY_MODE_EIO) {
|
2015-12-03 14:26:30 +00:00
|
|
|
DMEMIT(" ");
|
2015-03-18 15:52:14 +00:00
|
|
|
switch (v->mode) {
|
|
|
|
case DM_VERITY_MODE_LOGGING:
|
|
|
|
DMEMIT(DM_VERITY_OPT_LOGGING);
|
|
|
|
break;
|
|
|
|
case DM_VERITY_MODE_RESTART:
|
|
|
|
DMEMIT(DM_VERITY_OPT_RESTART);
|
|
|
|
break;
|
2020-06-18 06:56:50 +00:00
|
|
|
case DM_VERITY_MODE_PANIC:
|
|
|
|
DMEMIT(DM_VERITY_OPT_PANIC);
|
|
|
|
break;
|
2015-03-18 15:52:14 +00:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
}
|
2024-10-02 14:03:41 +00:00
|
|
|
if (v->error_mode != DM_VERITY_MODE_EIO) {
|
|
|
|
DMEMIT(" ");
|
|
|
|
switch (v->error_mode) {
|
|
|
|
case DM_VERITY_MODE_RESTART:
|
|
|
|
DMEMIT(DM_VERITY_OPT_ERROR_RESTART);
|
|
|
|
break;
|
|
|
|
case DM_VERITY_MODE_PANIC:
|
|
|
|
DMEMIT(DM_VERITY_OPT_ERROR_PANIC);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
}
|
2015-12-03 14:26:31 +00:00
|
|
|
if (v->zero_digest)
|
|
|
|
DMEMIT(" " DM_VERITY_OPT_IGN_ZEROES);
|
2018-03-23 01:18:04 +00:00
|
|
|
if (v->validated_blocks)
|
|
|
|
DMEMIT(" " DM_VERITY_OPT_AT_MOST_ONCE);
|
2024-01-30 09:11:55 +00:00
|
|
|
if (v->use_bh_wq)
|
2022-07-22 09:38:23 +00:00
|
|
|
DMEMIT(" " DM_VERITY_OPT_TASKLET_VERIFY);
|
2015-12-03 14:26:30 +00:00
|
|
|
sz = verity_fec_status_table(v, sz, result, maxlen);
|
2019-07-18 00:46:15 +00:00
|
|
|
if (v->signature_key_desc)
|
|
|
|
DMEMIT(" " DM_VERITY_ROOT_HASH_VERIFICATION_OPT_SIG_KEY
|
|
|
|
" %s", v->signature_key_desc);
|
2012-03-28 17:43:38 +00:00
|
|
|
break;
|
2021-07-13 00:49:03 +00:00
|
|
|
|
|
|
|
case STATUSTYPE_IMA:
|
|
|
|
DMEMIT_TARGET_NAME_VERSION(ti->type);
|
|
|
|
DMEMIT(",hash_failed=%c", v->hash_failed ? 'C' : 'V');
|
|
|
|
DMEMIT(",verity_version=%u", v->version);
|
|
|
|
DMEMIT(",data_device_name=%s", v->data_dev->name);
|
|
|
|
DMEMIT(",hash_device_name=%s", v->hash_dev->name);
|
|
|
|
DMEMIT(",verity_algorithm=%s", v->alg_name);
|
|
|
|
|
|
|
|
DMEMIT(",root_digest=");
|
|
|
|
for (x = 0; x < v->digest_size; x++)
|
|
|
|
DMEMIT("%02x", v->root_digest[x]);
|
|
|
|
|
|
|
|
DMEMIT(",salt=");
|
|
|
|
if (!v->salt_size)
|
|
|
|
DMEMIT("-");
|
|
|
|
else
|
|
|
|
for (x = 0; x < v->salt_size; x++)
|
|
|
|
DMEMIT("%02x", v->salt[x]);
|
|
|
|
|
|
|
|
DMEMIT(",ignore_zero_blocks=%c", v->zero_digest ? 'y' : 'n');
|
|
|
|
DMEMIT(",check_at_most_once=%c", v->validated_blocks ? 'y' : 'n');
|
2021-08-13 21:38:00 +00:00
|
|
|
if (v->signature_key_desc)
|
|
|
|
DMEMIT(",root_hash_sig_key_desc=%s", v->signature_key_desc);
|
2021-07-13 00:49:03 +00:00
|
|
|
|
|
|
|
if (v->mode != DM_VERITY_MODE_EIO) {
|
|
|
|
DMEMIT(",verity_mode=");
|
|
|
|
switch (v->mode) {
|
|
|
|
case DM_VERITY_MODE_LOGGING:
|
|
|
|
DMEMIT(DM_VERITY_OPT_LOGGING);
|
|
|
|
break;
|
|
|
|
case DM_VERITY_MODE_RESTART:
|
|
|
|
DMEMIT(DM_VERITY_OPT_RESTART);
|
|
|
|
break;
|
|
|
|
case DM_VERITY_MODE_PANIC:
|
|
|
|
DMEMIT(DM_VERITY_OPT_PANIC);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
DMEMIT("invalid");
|
|
|
|
}
|
|
|
|
}
|
2024-10-02 14:03:41 +00:00
|
|
|
if (v->error_mode != DM_VERITY_MODE_EIO) {
|
|
|
|
DMEMIT(",verity_error_mode=");
|
|
|
|
switch (v->error_mode) {
|
|
|
|
case DM_VERITY_MODE_RESTART:
|
|
|
|
DMEMIT(DM_VERITY_OPT_ERROR_RESTART);
|
|
|
|
break;
|
|
|
|
case DM_VERITY_MODE_PANIC:
|
|
|
|
DMEMIT(DM_VERITY_OPT_ERROR_PANIC);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
DMEMIT("invalid");
|
|
|
|
}
|
|
|
|
}
|
2021-07-13 00:49:03 +00:00
|
|
|
DMEMIT(";");
|
|
|
|
break;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-03 20:54:10 +00:00
|
|
|
static int verity_prepare_ioctl(struct dm_target *ti, struct block_device **bdev)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
2015-10-15 12:10:50 +00:00
|
|
|
|
|
|
|
*bdev = v->data_dev->bdev;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2021-10-18 10:11:05 +00:00
|
|
|
if (v->data_start || ti->len != bdev_nr_sectors(v->data_dev->bdev))
|
2015-10-15 12:10:50 +00:00
|
|
|
return 1;
|
|
|
|
return 0;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int verity_iterate_devices(struct dm_target *ti,
|
|
|
|
iterate_devices_callout_fn fn, void *data)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
|
|
|
|
return fn(ti, v->data_dev, v->data_start, ti->len, data);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void verity_io_hints(struct dm_target *ti, struct queue_limits *limits)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
|
|
|
|
if (limits->logical_block_size < 1 << v->data_dev_block_bits)
|
|
|
|
limits->logical_block_size = 1 << v->data_dev_block_bits;
|
|
|
|
|
|
|
|
if (limits->physical_block_size < 1 << v->data_dev_block_bits)
|
|
|
|
limits->physical_block_size = 1 << v->data_dev_block_bits;
|
|
|
|
|
2024-07-03 13:12:08 +00:00
|
|
|
limits->io_min = limits->logical_block_size;
|
2024-07-02 14:39:51 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Similar to what dm-crypt does, opt dm-verity out of support for
|
|
|
|
* direct I/O that is aligned to less than the traditional direct I/O
|
|
|
|
* alignment requirement of logical_block_size. This prevents dm-verity
|
|
|
|
* data blocks from crossing pages, eliminating various edge cases.
|
|
|
|
*/
|
|
|
|
limits->dma_alignment = limits->logical_block_size - 1;
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
#ifdef CONFIG_SECURITY
|
|
|
|
|
|
|
|
static int verity_init_sig(struct dm_verity *v, const void *sig,
|
|
|
|
size_t sig_size)
|
|
|
|
{
|
|
|
|
v->sig_size = sig_size;
|
|
|
|
|
|
|
|
if (sig) {
|
|
|
|
v->root_digest_sig = kmemdup(sig, v->sig_size, GFP_KERNEL);
|
|
|
|
if (!v->root_digest_sig)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void verity_free_sig(struct dm_verity *v)
|
|
|
|
{
|
|
|
|
kfree(v->root_digest_sig);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static inline int verity_init_sig(struct dm_verity *v, const void *sig,
|
|
|
|
size_t sig_size)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void verity_free_sig(struct dm_verity *v)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY */
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
static void verity_dtr(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
|
|
|
|
if (v->verify_wq)
|
|
|
|
destroy_workqueue(v->verify_wq);
|
|
|
|
|
2024-02-19 20:28:09 +00:00
|
|
|
mempool_exit(&v->recheck_pool);
|
|
|
|
if (v->io)
|
|
|
|
dm_io_client_destroy(v->io);
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
if (v->bufio)
|
|
|
|
dm_bufio_client_destroy(v->bufio);
|
|
|
|
|
2018-03-23 01:18:04 +00:00
|
|
|
kvfree(v->validated_blocks);
|
2012-03-28 17:43:38 +00:00
|
|
|
kfree(v->salt);
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
kfree(v->initial_hashstate);
|
2012-03-28 17:43:38 +00:00
|
|
|
kfree(v->root_digest);
|
2015-12-03 14:26:31 +00:00
|
|
|
kfree(v->zero_digest);
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
verity_free_sig(v);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
if (v->ahash_tfm) {
|
|
|
|
static_branch_dec(&ahash_enabled);
|
|
|
|
crypto_free_ahash(v->ahash_tfm);
|
|
|
|
} else {
|
|
|
|
crypto_free_shash(v->shash_tfm);
|
|
|
|
}
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
kfree(v->alg_name);
|
|
|
|
|
|
|
|
if (v->hash_dev)
|
|
|
|
dm_put_device(ti, v->hash_dev);
|
|
|
|
|
|
|
|
if (v->data_dev)
|
|
|
|
dm_put_device(ti, v->data_dev);
|
|
|
|
|
2015-12-03 14:26:30 +00:00
|
|
|
verity_fec_dtr(v);
|
|
|
|
|
2019-07-18 00:46:15 +00:00
|
|
|
kfree(v->signature_key_desc);
|
|
|
|
|
2024-01-30 09:11:55 +00:00
|
|
|
if (v->use_bh_wq)
|
|
|
|
static_branch_dec(&use_bh_wq_enabled);
|
2022-07-25 20:52:17 +00:00
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
kfree(v);
|
2023-03-01 11:34:15 +00:00
|
|
|
|
|
|
|
dm_audit_log_dtr(DM_MSG_PREFIX, ti, 1);
|
2012-03-28 17:43:38 +00:00
|
|
|
}
|
|
|
|
|
2018-03-23 01:18:04 +00:00
|
|
|
static int verity_alloc_most_once(struct dm_verity *v)
|
|
|
|
{
|
|
|
|
struct dm_target *ti = v->ti;
|
|
|
|
|
|
|
|
/* the bitset can only handle INT_MAX blocks */
|
|
|
|
if (v->data_blocks > INT_MAX) {
|
|
|
|
ti->error = "device too large to use check_at_most_once";
|
|
|
|
return -E2BIG;
|
|
|
|
}
|
|
|
|
|
treewide: kvzalloc() -> kvcalloc()
The kvzalloc() function has a 2-factor argument form, kvcalloc(). This
patch replaces cases of:
kvzalloc(a * b, gfp)
with:
kvcalloc(a * b, gfp)
as well as handling cases of:
kvzalloc(a * b * c, gfp)
with:
kvzalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kvcalloc(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kvzalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kvzalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kvzalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kvzalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kvzalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kvzalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kvzalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kvzalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kvzalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kvzalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kvzalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kvzalloc
+ kvcalloc
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kvzalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kvzalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kvzalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kvzalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kvzalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kvzalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kvzalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kvzalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kvzalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kvzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kvzalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kvzalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kvzalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kvzalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kvzalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kvzalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kvzalloc(C1 * C2 * C3, ...)
|
kvzalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kvzalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kvzalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kvzalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kvzalloc(sizeof(THING) * C2, ...)
|
kvzalloc(sizeof(TYPE) * C2, ...)
|
kvzalloc(C1 * C2 * C3, ...)
|
kvzalloc(C1 * C2, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kvzalloc
+ kvcalloc
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kvzalloc
+ kvcalloc
(
- (E1) * E2
+ E1, E2
, ...)
|
- kvzalloc
+ kvcalloc
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kvzalloc
+ kvcalloc
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-12 21:04:48 +00:00
|
|
|
v->validated_blocks = kvcalloc(BITS_TO_LONGS(v->data_blocks),
|
|
|
|
sizeof(unsigned long),
|
|
|
|
GFP_KERNEL);
|
2018-03-23 01:18:04 +00:00
|
|
|
if (!v->validated_blocks) {
|
|
|
|
ti->error = "failed to allocate bitset for check_at_most_once";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2015-12-03 14:26:31 +00:00
|
|
|
static int verity_alloc_zero_digest(struct dm_verity *v)
|
|
|
|
{
|
|
|
|
int r = -ENOMEM;
|
2024-07-02 14:40:41 +00:00
|
|
|
struct dm_verity_io *io;
|
2015-12-03 14:26:31 +00:00
|
|
|
u8 *zero_data;
|
|
|
|
|
|
|
|
v->zero_digest = kmalloc(v->digest_size, GFP_KERNEL);
|
|
|
|
|
|
|
|
if (!v->zero_digest)
|
|
|
|
return r;
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
io = kmalloc(sizeof(*io) + v->hash_reqsize, GFP_KERNEL);
|
2015-12-03 14:26:31 +00:00
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
if (!io)
|
2015-12-03 14:26:31 +00:00
|
|
|
return r; /* verity_dtr will free zero_digest */
|
|
|
|
|
|
|
|
zero_data = kzalloc(1 << v->data_dev_block_bits, GFP_KERNEL);
|
|
|
|
|
|
|
|
if (!zero_data)
|
|
|
|
goto out;
|
|
|
|
|
2024-07-02 14:40:41 +00:00
|
|
|
r = verity_hash(v, io, zero_data, 1 << v->data_dev_block_bits,
|
dm-verity: don't use blocking calls from tasklets
The commit 5721d4e5a9cd enhanced dm-verity, so that it can verify blocks
from tasklets rather than from workqueues. This reportedly improves
performance significantly.
However, dm-verity was using the flag CRYPTO_TFM_REQ_MAY_SLEEP from
tasklets which resulted in warnings about sleeping function being called
from non-sleeping context.
BUG: sleeping function called from invalid context at crypto/internal.h:206
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 14, name: ksoftirqd/0
preempt_count: 100, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 PID: 14 Comm: ksoftirqd/0 Tainted: G W 6.7.0-rc1 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x32/0x50
__might_resched+0x110/0x160
crypto_hash_walk_done+0x54/0xb0
shash_ahash_update+0x51/0x60
verity_hash_update.isra.0+0x4a/0x130 [dm_verity]
verity_verify_io+0x165/0x550 [dm_verity]
? free_unref_page+0xdf/0x170
? psi_group_change+0x113/0x390
verity_tasklet+0xd/0x70 [dm_verity]
tasklet_action_common.isra.0+0xb3/0xc0
__do_softirq+0xaf/0x1ec
? smpboot_thread_fn+0x1d/0x200
? sort_range+0x20/0x20
run_ksoftirqd+0x15/0x30
smpboot_thread_fn+0xed/0x200
kthread+0xdc/0x110
? kthread_complete_and_exit+0x20/0x20
ret_from_fork+0x28/0x40
? kthread_complete_and_exit+0x20/0x20
ret_from_fork_asm+0x11/0x20
</TASK>
This commit fixes dm-verity so that it doesn't use the flags
CRYPTO_TFM_REQ_MAY_SLEEP and CRYPTO_TFM_REQ_MAY_BACKLOG from tasklets. The
crypto API would do GFP_ATOMIC allocation instead, it could return -ENOMEM
and we catch -ENOMEM in verity_tasklet and requeue the request to the
workqueue.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org # v6.0+
Fixes: 5721d4e5a9cd ("dm verity: Add optional "try_verify_in_tasklet" feature")
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2023-11-17 17:37:25 +00:00
|
|
|
v->zero_digest, true);
|
2015-12-03 14:26:31 +00:00
|
|
|
|
|
|
|
out:
|
2024-07-02 14:40:41 +00:00
|
|
|
kfree(io);
|
2015-12-03 14:26:31 +00:00
|
|
|
kfree(zero_data);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2021-03-11 12:10:51 +00:00
|
|
|
static inline bool verity_is_verity_mode(const char *arg_name)
|
|
|
|
{
|
|
|
|
return (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING) ||
|
|
|
|
!strcasecmp(arg_name, DM_VERITY_OPT_RESTART) ||
|
|
|
|
!strcasecmp(arg_name, DM_VERITY_OPT_PANIC));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int verity_parse_verity_mode(struct dm_verity *v, const char *arg_name)
|
|
|
|
{
|
|
|
|
if (v->mode)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcasecmp(arg_name, DM_VERITY_OPT_LOGGING))
|
|
|
|
v->mode = DM_VERITY_MODE_LOGGING;
|
|
|
|
else if (!strcasecmp(arg_name, DM_VERITY_OPT_RESTART))
|
|
|
|
v->mode = DM_VERITY_MODE_RESTART;
|
|
|
|
else if (!strcasecmp(arg_name, DM_VERITY_OPT_PANIC))
|
|
|
|
v->mode = DM_VERITY_MODE_PANIC;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2024-10-02 14:03:41 +00:00
|
|
|
static inline bool verity_is_verity_error_mode(const char *arg_name)
|
|
|
|
{
|
|
|
|
return (!strcasecmp(arg_name, DM_VERITY_OPT_ERROR_RESTART) ||
|
|
|
|
!strcasecmp(arg_name, DM_VERITY_OPT_ERROR_PANIC));
|
|
|
|
}
|
|
|
|
|
|
|
|
static int verity_parse_verity_error_mode(struct dm_verity *v, const char *arg_name)
|
|
|
|
{
|
|
|
|
if (v->error_mode)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strcasecmp(arg_name, DM_VERITY_OPT_ERROR_RESTART))
|
|
|
|
v->error_mode = DM_VERITY_MODE_RESTART;
|
|
|
|
else if (!strcasecmp(arg_name, DM_VERITY_OPT_ERROR_PANIC))
|
|
|
|
v->error_mode = DM_VERITY_MODE_PANIC;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-07-18 00:46:15 +00:00
|
|
|
static int verity_parse_opt_args(struct dm_arg_set *as, struct dm_verity *v,
|
2022-07-26 15:29:50 +00:00
|
|
|
struct dm_verity_sig_opts *verify_args,
|
|
|
|
bool only_modifier_opts)
|
2015-11-05 02:02:32 +00:00
|
|
|
{
|
2022-08-09 22:07:28 +00:00
|
|
|
int r = 0;
|
2023-01-25 20:14:58 +00:00
|
|
|
unsigned int argc;
|
2015-11-05 02:02:32 +00:00
|
|
|
struct dm_target *ti = v->ti;
|
|
|
|
const char *arg_name;
|
|
|
|
|
2017-06-22 18:32:45 +00:00
|
|
|
static const struct dm_arg _args[] = {
|
2015-11-05 02:02:32 +00:00
|
|
|
{0, DM_VERITY_OPTS_MAX, "Invalid number of feature args"},
|
|
|
|
};
|
|
|
|
|
|
|
|
r = dm_read_arg_group(_args, as, &argc, &ti->error);
|
|
|
|
if (r)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!argc)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
do {
|
|
|
|
arg_name = dm_shift_arg(as);
|
|
|
|
argc--;
|
|
|
|
|
2021-03-11 12:10:51 +00:00
|
|
|
if (verity_is_verity_mode(arg_name)) {
|
2022-07-26 15:29:50 +00:00
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
2021-03-11 12:10:51 +00:00
|
|
|
r = verity_parse_verity_mode(v, arg_name);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Conflicting error handling parameters";
|
|
|
|
return r;
|
|
|
|
}
|
2020-06-18 06:56:50 +00:00
|
|
|
continue;
|
|
|
|
|
2024-10-02 14:03:41 +00:00
|
|
|
} else if (verity_is_verity_error_mode(arg_name)) {
|
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
|
|
|
r = verity_parse_verity_error_mode(v, arg_name);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Conflicting error handling parameters";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
|
2015-12-03 14:26:31 +00:00
|
|
|
} else if (!strcasecmp(arg_name, DM_VERITY_OPT_IGN_ZEROES)) {
|
2022-07-26 15:29:50 +00:00
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
2015-12-03 14:26:31 +00:00
|
|
|
r = verity_alloc_zero_digest(v);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Cannot allocate zero digest";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
|
2018-03-23 01:18:04 +00:00
|
|
|
} else if (!strcasecmp(arg_name, DM_VERITY_OPT_AT_MOST_ONCE)) {
|
2022-07-26 15:29:50 +00:00
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
2018-03-23 01:18:04 +00:00
|
|
|
r = verity_alloc_most_once(v);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
continue;
|
|
|
|
|
2022-07-22 09:38:23 +00:00
|
|
|
} else if (!strcasecmp(arg_name, DM_VERITY_OPT_TASKLET_VERIFY)) {
|
2024-01-30 09:11:55 +00:00
|
|
|
v->use_bh_wq = true;
|
|
|
|
static_branch_inc(&use_bh_wq_enabled);
|
2022-07-22 09:38:23 +00:00
|
|
|
continue;
|
|
|
|
|
2015-12-03 14:26:30 +00:00
|
|
|
} else if (verity_is_fec_opt_arg(arg_name)) {
|
2022-07-26 15:29:50 +00:00
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
2015-12-03 14:26:30 +00:00
|
|
|
r = verity_fec_parse_opt_args(as, v, &argc, arg_name);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
continue;
|
2022-07-22 09:38:23 +00:00
|
|
|
|
2019-07-18 00:46:15 +00:00
|
|
|
} else if (verity_verify_is_sig_opt_arg(arg_name)) {
|
2022-07-26 15:29:50 +00:00
|
|
|
if (only_modifier_opts)
|
|
|
|
continue;
|
2019-07-18 00:46:15 +00:00
|
|
|
r = verity_verify_sig_parse_opt_args(as, v,
|
|
|
|
verify_args,
|
|
|
|
&argc, arg_name);
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
continue;
|
2022-08-09 22:07:28 +00:00
|
|
|
|
|
|
|
} else if (only_modifier_opts) {
|
|
|
|
/*
|
|
|
|
* Ignore unrecognized opt, could easily be an extra
|
|
|
|
* argument to an option whose parsing was skipped.
|
|
|
|
* Normal parsing (@only_modifier_opts=false) will
|
|
|
|
* properly parse all options (and their extra args).
|
|
|
|
*/
|
|
|
|
continue;
|
2015-11-05 02:02:32 +00:00
|
|
|
}
|
|
|
|
|
2022-08-09 22:07:28 +00:00
|
|
|
DMERR("Unrecognized verity feature request: %s", arg_name);
|
2015-11-05 02:02:32 +00:00
|
|
|
ti->error = "Unrecognized verity feature request";
|
|
|
|
return -EINVAL;
|
|
|
|
} while (argc && !r);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2024-07-02 14:37:45 +00:00
|
|
|
static int verity_setup_hash_alg(struct dm_verity *v, const char *alg_name)
|
|
|
|
{
|
|
|
|
struct dm_target *ti = v->ti;
|
|
|
|
struct crypto_ahash *ahash;
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
struct crypto_shash *shash = NULL;
|
|
|
|
const char *driver_name;
|
2024-07-02 14:37:45 +00:00
|
|
|
|
|
|
|
v->alg_name = kstrdup(alg_name, GFP_KERNEL);
|
|
|
|
if (!v->alg_name) {
|
|
|
|
ti->error = "Cannot allocate algorithm name";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
/*
|
|
|
|
* Allocate the hash transformation object that this dm-verity instance
|
|
|
|
* will use. The vast majority of dm-verity users use CPU-based
|
|
|
|
* hashing, so when possible use the shash API to minimize the crypto
|
|
|
|
* API overhead. If the ahash API resolves to a different driver
|
|
|
|
* (likely an off-CPU hardware offload), use ahash instead. Also use
|
|
|
|
* ahash if the obsolete dm-verity format with the appended salt is
|
|
|
|
* being used, so that quirk only needs to be handled in one place.
|
|
|
|
*/
|
2024-07-02 14:37:45 +00:00
|
|
|
ahash = crypto_alloc_ahash(alg_name, 0,
|
|
|
|
v->use_bh_wq ? CRYPTO_ALG_ASYNC : 0);
|
|
|
|
if (IS_ERR(ahash)) {
|
|
|
|
ti->error = "Cannot initialize hash function";
|
|
|
|
return PTR_ERR(ahash);
|
|
|
|
}
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
driver_name = crypto_ahash_driver_name(ahash);
|
|
|
|
if (v->version >= 1 /* salt prepended, not appended? */) {
|
|
|
|
shash = crypto_alloc_shash(alg_name, 0, 0);
|
|
|
|
if (!IS_ERR(shash) &&
|
|
|
|
strcmp(crypto_shash_driver_name(shash), driver_name) != 0) {
|
|
|
|
/*
|
|
|
|
* ahash gave a different driver than shash, so probably
|
|
|
|
* this is a case of real hardware offload. Use ahash.
|
|
|
|
*/
|
|
|
|
crypto_free_shash(shash);
|
|
|
|
shash = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!IS_ERR_OR_NULL(shash)) {
|
|
|
|
crypto_free_ahash(ahash);
|
|
|
|
ahash = NULL;
|
|
|
|
v->shash_tfm = shash;
|
|
|
|
v->digest_size = crypto_shash_digestsize(shash);
|
|
|
|
v->hash_reqsize = sizeof(struct shash_desc) +
|
|
|
|
crypto_shash_descsize(shash);
|
|
|
|
DMINFO("%s using shash \"%s\"", alg_name, driver_name);
|
|
|
|
} else {
|
|
|
|
v->ahash_tfm = ahash;
|
|
|
|
static_branch_inc(&ahash_enabled);
|
|
|
|
v->digest_size = crypto_ahash_digestsize(ahash);
|
|
|
|
v->hash_reqsize = sizeof(struct ahash_request) +
|
|
|
|
crypto_ahash_reqsize(ahash);
|
|
|
|
DMINFO("%s using ahash \"%s\"", alg_name, driver_name);
|
|
|
|
}
|
2024-07-02 14:37:45 +00:00
|
|
|
if ((1 << v->hash_dev_block_bits) < v->digest_size * 2) {
|
|
|
|
ti->error = "Digest size too big";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int verity_setup_salt_and_hashstate(struct dm_verity *v, const char *arg)
|
|
|
|
{
|
|
|
|
struct dm_target *ti = v->ti;
|
|
|
|
|
|
|
|
if (strcmp(arg, "-") != 0) {
|
|
|
|
v->salt_size = strlen(arg) / 2;
|
|
|
|
v->salt = kmalloc(v->salt_size, GFP_KERNEL);
|
|
|
|
if (!v->salt) {
|
|
|
|
ti->error = "Cannot allocate salt";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
if (strlen(arg) != v->salt_size * 2 ||
|
|
|
|
hex2bin(v->salt, arg, v->salt_size)) {
|
|
|
|
ti->error = "Invalid salt";
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (v->shash_tfm) {
|
|
|
|
SHASH_DESC_ON_STACK(desc, v->shash_tfm);
|
|
|
|
int r;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute the pre-salted hash state that can be passed to
|
|
|
|
* crypto_shash_import() for each block later.
|
|
|
|
*/
|
|
|
|
v->initial_hashstate = kmalloc(
|
|
|
|
crypto_shash_statesize(v->shash_tfm), GFP_KERNEL);
|
|
|
|
if (!v->initial_hashstate) {
|
|
|
|
ti->error = "Cannot allocate initial hash state";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
desc->tfm = v->shash_tfm;
|
|
|
|
r = crypto_shash_init(desc) ?:
|
|
|
|
crypto_shash_update(desc, v->salt, v->salt_size) ?:
|
|
|
|
crypto_shash_export(desc, v->initial_hashstate);
|
|
|
|
if (r) {
|
|
|
|
ti->error = "Cannot set up initial hash state";
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
}
|
2024-07-02 14:37:45 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
/*
|
|
|
|
* Target parameters:
|
|
|
|
* <version> The current format is version 1.
|
|
|
|
* Vsn 0 is compatible with original Chromium OS releases.
|
|
|
|
* <data device>
|
|
|
|
* <hash device>
|
|
|
|
* <data block size>
|
|
|
|
* <hash block size>
|
|
|
|
* <the number of data blocks>
|
|
|
|
* <hash start block>
|
|
|
|
* <algorithm>
|
|
|
|
* <digest>
|
|
|
|
* <salt> Hex string or "-" if no salt.
|
|
|
|
*/
|
2023-01-25 20:14:58 +00:00
|
|
|
static int verity_ctr(struct dm_target *ti, unsigned int argc, char **argv)
|
2012-03-28 17:43:38 +00:00
|
|
|
{
|
|
|
|
struct dm_verity *v;
|
2019-07-18 00:46:15 +00:00
|
|
|
struct dm_verity_sig_opts verify_args = {0};
|
2015-03-18 15:52:14 +00:00
|
|
|
struct dm_arg_set as;
|
2015-11-05 02:02:32 +00:00
|
|
|
unsigned int num;
|
2012-03-28 17:43:38 +00:00
|
|
|
unsigned long long num_ll;
|
|
|
|
int r;
|
|
|
|
int i;
|
|
|
|
sector_t hash_position;
|
|
|
|
char dummy;
|
2019-07-18 00:46:15 +00:00
|
|
|
char *root_hash_digest_to_validate;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
v = kzalloc(sizeof(struct dm_verity), GFP_KERNEL);
|
|
|
|
if (!v) {
|
|
|
|
ti->error = "Cannot allocate verity structure";
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
ti->private = v;
|
|
|
|
v->ti = ti;
|
|
|
|
|
2015-12-03 14:26:30 +00:00
|
|
|
r = verity_fec_ctr_alloc(v);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
2023-06-08 11:02:55 +00:00
|
|
|
if ((dm_table_get_mode(ti->table) & ~BLK_OPEN_READ)) {
|
2012-03-28 17:43:38 +00:00
|
|
|
ti->error = "Device must be readonly";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
if (argc < 10) {
|
|
|
|
ti->error = "Not enough arguments";
|
2012-03-28 17:43:38 +00:00
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2022-07-26 15:29:50 +00:00
|
|
|
/* Parse optional parameters that modify primary args */
|
|
|
|
if (argc > 10) {
|
|
|
|
as.argc = argc - 10;
|
|
|
|
as.argv = argv + 10;
|
|
|
|
r = verity_parse_opt_args(&as, v, &verify_args, true);
|
|
|
|
if (r < 0)
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2013-07-10 22:41:17 +00:00
|
|
|
if (sscanf(argv[0], "%u%c", &num, &dummy) != 1 ||
|
|
|
|
num > 1) {
|
2012-03-28 17:43:38 +00:00
|
|
|
ti->error = "Invalid version";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
v->version = num;
|
|
|
|
|
2023-06-08 11:02:55 +00:00
|
|
|
r = dm_get_device(ti, argv[1], BLK_OPEN_READ, &v->data_dev);
|
2012-03-28 17:43:38 +00:00
|
|
|
if (r) {
|
|
|
|
ti->error = "Data device lookup failed";
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2023-06-08 11:02:55 +00:00
|
|
|
r = dm_get_device(ti, argv[2], BLK_OPEN_READ, &v->hash_dev);
|
2012-03-28 17:43:38 +00:00
|
|
|
if (r) {
|
2016-09-08 19:21:28 +00:00
|
|
|
ti->error = "Hash device lookup failed";
|
2012-03-28 17:43:38 +00:00
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sscanf(argv[3], "%u%c", &num, &dummy) != 1 ||
|
|
|
|
!num || (num & (num - 1)) ||
|
|
|
|
num < bdev_logical_block_size(v->data_dev->bdev) ||
|
|
|
|
num > PAGE_SIZE) {
|
|
|
|
ti->error = "Invalid data device block size";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
2013-07-10 22:41:17 +00:00
|
|
|
v->data_dev_block_bits = __ffs(num);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
if (sscanf(argv[4], "%u%c", &num, &dummy) != 1 ||
|
|
|
|
!num || (num & (num - 1)) ||
|
|
|
|
num < bdev_logical_block_size(v->hash_dev->bdev) ||
|
|
|
|
num > INT_MAX) {
|
|
|
|
ti->error = "Invalid hash device block size";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
2013-07-10 22:41:17 +00:00
|
|
|
v->hash_dev_block_bits = __ffs(num);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
if (sscanf(argv[5], "%llu%c", &num_ll, &dummy) != 1 ||
|
2012-09-26 22:45:48 +00:00
|
|
|
(sector_t)(num_ll << (v->data_dev_block_bits - SECTOR_SHIFT))
|
|
|
|
>> (v->data_dev_block_bits - SECTOR_SHIFT) != num_ll) {
|
2012-03-28 17:43:38 +00:00
|
|
|
ti->error = "Invalid data blocks";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
v->data_blocks = num_ll;
|
|
|
|
|
|
|
|
if (ti->len > (v->data_blocks << (v->data_dev_block_bits - SECTOR_SHIFT))) {
|
|
|
|
ti->error = "Data device is too small";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (sscanf(argv[6], "%llu%c", &num_ll, &dummy) != 1 ||
|
2012-09-26 22:45:48 +00:00
|
|
|
(sector_t)(num_ll << (v->hash_dev_block_bits - SECTOR_SHIFT))
|
|
|
|
>> (v->hash_dev_block_bits - SECTOR_SHIFT) != num_ll) {
|
2012-03-28 17:43:38 +00:00
|
|
|
ti->error = "Invalid hash start";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
v->hash_start = num_ll;
|
|
|
|
|
2024-07-02 14:37:45 +00:00
|
|
|
r = verity_setup_hash_alg(v, argv[7]);
|
|
|
|
if (r)
|
2012-03-28 17:43:38 +00:00
|
|
|
goto bad;
|
|
|
|
|
|
|
|
v->root_digest = kmalloc(v->digest_size, GFP_KERNEL);
|
|
|
|
if (!v->root_digest) {
|
|
|
|
ti->error = "Cannot allocate root digest";
|
|
|
|
r = -ENOMEM;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
if (strlen(argv[8]) != v->digest_size * 2 ||
|
|
|
|
hex2bin(v->root_digest, argv[8], v->digest_size)) {
|
|
|
|
ti->error = "Invalid root digest";
|
|
|
|
r = -EINVAL;
|
|
|
|
goto bad;
|
|
|
|
}
|
2019-07-18 00:46:15 +00:00
|
|
|
root_hash_digest_to_validate = argv[8];
|
2012-03-28 17:43:38 +00:00
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
r = verity_setup_salt_and_hashstate(v, argv[9]);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2015-03-18 15:52:14 +00:00
|
|
|
argv += 10;
|
|
|
|
argc -= 10;
|
|
|
|
|
|
|
|
/* Optional parameters */
|
|
|
|
if (argc) {
|
|
|
|
as.argc = argc;
|
|
|
|
as.argv = argv;
|
2022-07-26 15:29:50 +00:00
|
|
|
r = verity_parse_opt_args(&as, v, &verify_args, false);
|
2015-11-05 02:02:32 +00:00
|
|
|
if (r < 0)
|
2015-03-18 15:52:14 +00:00
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2019-07-18 00:46:15 +00:00
|
|
|
/* Root hash signature is a optional parameter*/
|
|
|
|
r = verity_verify_root_hash(root_hash_digest_to_validate,
|
|
|
|
strlen(root_hash_digest_to_validate),
|
|
|
|
verify_args.sig,
|
|
|
|
verify_args.sig_size);
|
|
|
|
if (r < 0) {
|
|
|
|
ti->error = "Root hash verification failed";
|
|
|
|
goto bad;
|
|
|
|
}
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
|
|
|
|
r = verity_init_sig(v, verify_args.sig, verify_args.sig_size);
|
|
|
|
if (r < 0) {
|
|
|
|
ti->error = "Cannot allocate root digest signature";
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
v->hash_per_block_bits =
|
2013-07-10 22:41:17 +00:00
|
|
|
__fls((1 << v->hash_dev_block_bits) / v->digest_size);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
|
|
|
v->levels = 0;
|
|
|
|
if (v->data_blocks)
|
|
|
|
while (v->hash_per_block_bits * v->levels < 64 &&
|
|
|
|
(unsigned long long)(v->data_blocks - 1) >>
|
|
|
|
(v->hash_per_block_bits * v->levels))
|
|
|
|
v->levels++;
|
|
|
|
|
|
|
|
if (v->levels > DM_VERITY_MAX_LEVELS) {
|
|
|
|
ti->error = "Too many tree levels";
|
|
|
|
r = -E2BIG;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
hash_position = v->hash_start;
|
|
|
|
for (i = v->levels - 1; i >= 0; i--) {
|
|
|
|
sector_t s;
|
2023-02-01 22:42:29 +00:00
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
v->hash_level_block[i] = hash_position;
|
2013-07-10 22:41:16 +00:00
|
|
|
s = (v->data_blocks + ((sector_t)1 << ((i + 1) * v->hash_per_block_bits)) - 1)
|
|
|
|
>> ((i + 1) * v->hash_per_block_bits);
|
2012-03-28 17:43:38 +00:00
|
|
|
if (hash_position + s < hash_position) {
|
|
|
|
ti->error = "Hash device offset overflow";
|
|
|
|
r = -E2BIG;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
hash_position += s;
|
|
|
|
}
|
|
|
|
v->hash_blocks = hash_position;
|
|
|
|
|
2024-02-19 20:28:09 +00:00
|
|
|
r = mempool_init_page_pool(&v->recheck_pool, 1, 0);
|
|
|
|
if (unlikely(r)) {
|
|
|
|
ti->error = "Cannot allocate mempool";
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
v->io = dm_io_client_create();
|
|
|
|
if (IS_ERR(v->io)) {
|
|
|
|
r = PTR_ERR(v->io);
|
|
|
|
v->io = NULL;
|
|
|
|
ti->error = "Cannot allocate dm io";
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
v->bufio = dm_bufio_client_create(v->hash_dev->bdev,
|
|
|
|
1 << v->hash_dev_block_bits, 1, sizeof(struct buffer_aux),
|
2022-07-22 09:38:23 +00:00
|
|
|
dm_bufio_alloc_callback, NULL,
|
2024-01-30 09:11:55 +00:00
|
|
|
v->use_bh_wq ? DM_BUFIO_CLIENT_NO_SLEEP : 0);
|
2012-03-28 17:43:38 +00:00
|
|
|
if (IS_ERR(v->bufio)) {
|
|
|
|
ti->error = "Cannot initialize dm-bufio";
|
|
|
|
r = PTR_ERR(v->bufio);
|
|
|
|
v->bufio = NULL;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (dm_bufio_get_device_size(v->bufio) < v->hash_blocks) {
|
|
|
|
ti->error = "Hash device is too small";
|
|
|
|
r = -E2BIG;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
dm verity: enable WQ_HIGHPRI on verify_wq
WQ_HIGHPRI increases throughput and decreases disk latency when using
dm-verity. This is important in Android for camera startup speed.
The following tests were run by doing 60 seconds of random reads using
a dm-verity device backed by two ramdisks.
Without WQ_HIGHPRI
lat (usec): min=13, max=3947, avg=69.53, stdev=50.55
READ: bw=51.1MiB/s (53.6MB/s), 51.1MiB/s-51.1MiB/s (53.6MB/s-53.6MB/s)
With WQ_HIGHPRI:
lat (usec): min=13, max=7854, avg=31.15, stdev=30.42
READ: bw=116MiB/s (121MB/s), 116MiB/s-116MiB/s (121MB/s-121MB/s)
Further testing was done by measuring how long it takes to open a
camera on an Android device.
Without WQ_HIGHPRI
Total verity work queue wait times (ms):
880.960, 789.517, 898.852
With WQ_HIGHPRI:
Total verity work queue wait times (ms):
528.824, 439.191, 433.300
The average time to open the camera is reduced by 350ms (or 40-50%).
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-30 18:44:44 +00:00
|
|
|
/*
|
|
|
|
* Using WQ_HIGHPRI improves throughput and completion latency by
|
|
|
|
* reducing wait times when reading from a dm-verity device.
|
|
|
|
*
|
|
|
|
* Also as required for the "try_verify_in_tasklet" feature: WQ_HIGHPRI
|
2024-01-30 09:11:55 +00:00
|
|
|
* allows verify_wq to preempt softirq since verification in BH workqueue
|
dm verity: enable WQ_HIGHPRI on verify_wq
WQ_HIGHPRI increases throughput and decreases disk latency when using
dm-verity. This is important in Android for camera startup speed.
The following tests were run by doing 60 seconds of random reads using
a dm-verity device backed by two ramdisks.
Without WQ_HIGHPRI
lat (usec): min=13, max=3947, avg=69.53, stdev=50.55
READ: bw=51.1MiB/s (53.6MB/s), 51.1MiB/s-51.1MiB/s (53.6MB/s-53.6MB/s)
With WQ_HIGHPRI:
lat (usec): min=13, max=7854, avg=31.15, stdev=30.42
READ: bw=116MiB/s (121MB/s), 116MiB/s-116MiB/s (121MB/s-121MB/s)
Further testing was done by measuring how long it takes to open a
camera on an Android device.
Without WQ_HIGHPRI
Total verity work queue wait times (ms):
880.960, 789.517, 898.852
With WQ_HIGHPRI:
Total verity work queue wait times (ms):
528.824, 439.191, 433.300
The average time to open the camera is reduced by 350ms (or 40-50%).
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-08-30 18:44:44 +00:00
|
|
|
* will fall-back to using it for error handling (or if the bufio cache
|
|
|
|
* doesn't have required hashes).
|
|
|
|
*/
|
2023-02-02 01:23:48 +00:00
|
|
|
v->verify_wq = alloc_workqueue("kverityd", WQ_MEM_RECLAIM | WQ_HIGHPRI, 0);
|
2012-03-28 17:43:38 +00:00
|
|
|
if (!v->verify_wq) {
|
|
|
|
ti->error = "Cannot allocate workqueue";
|
|
|
|
r = -ENOMEM;
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
dm-verity: hash blocks with shash import+finup when possible
Currently dm-verity computes the hash of each block by using multiple
calls to the "ahash" crypto API. While the exact sequence depends on
the chosen dm-verity settings, in the vast majority of cases it is:
1. crypto_ahash_init()
2. crypto_ahash_update() [salt]
3. crypto_ahash_update() [data]
4. crypto_ahash_final()
This is inefficient for two main reasons:
- It makes multiple indirect calls, which is expensive on modern CPUs
especially when mitigations for CPU vulnerabilities are enabled.
Since the salt is the same across all blocks on a given dm-verity
device, a much more efficient sequence would be to do an import of the
pre-salted state, then a finup.
- It uses the ahash (asynchronous hash) API, despite the fact that
CPU-based hashing is almost always used in practice, and therefore it
experiences the overhead of the ahash-based wrapper for shash.
Because dm-verity was intentionally converted to ahash to support
off-CPU crypto accelerators, a full reversion to shash might not be
acceptable. Yet, we should still provide a fast path for shash with
the most common dm-verity settings.
Another reason for shash over ahash is that the upcoming multibuffer
hashing support, which is specific to CPU-based hashing, is much
better suited for shash than for ahash. Supporting it via ahash would
add significant complexity and overhead. And it's not possible for
the "same" code to properly support both multibuffer hashing and HW
accelerators at the same time anyway, given the different computation
models. Unfortunately there will always be code specific to each
model needed (for users who want to support both).
Therefore, this patch adds a new shash import+finup based fast path to
dm-verity. It is used automatically when appropriate. This makes
dm-verity optimized for what the vast majority of users want: CPU-based
hashing with the most common settings, while still retaining support for
rarer settings and off-CPU crypto accelerators.
In benchmarks with veritysetup's default parameters (SHA-256, 4K data
and hash block sizes, 32-byte salt), which also match the parameters
that Android currently uses, this patch improves block hashing
performance by about 15% on x86_64 using the SHA-NI instructions, or by
about 5% on arm64 using the ARMv8 SHA2 instructions. On x86_64 roughly
two-thirds of the improvement comes from the use of import and finup,
while the remaining third comes from the switch from ahash to shash.
Note that another benefit of using "import" to handle the salt is that
if the salt size is equal to the input size of the hash algorithm's
compression function, e.g. 64 bytes for SHA-256, then the performance is
exactly the same as no salt. This doesn't seem to be much better than
veritysetup's current default of 32-byte salts, due to the way SHA-256's
finalization padding works, but it should be marginally better.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2024-07-02 14:41:08 +00:00
|
|
|
ti->per_io_data_size = sizeof(struct dm_verity_io) + v->hash_reqsize;
|
2015-12-03 14:26:30 +00:00
|
|
|
|
|
|
|
r = verity_fec_ctr(v);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
2016-01-31 18:28:26 +00:00
|
|
|
ti->per_io_data_size = roundup(ti->per_io_data_size,
|
|
|
|
__alignof__(struct dm_verity_io));
|
2015-12-03 14:26:30 +00:00
|
|
|
|
2019-07-18 00:46:15 +00:00
|
|
|
verity_verify_sig_opts_cleanup(&verify_args);
|
|
|
|
|
2023-03-01 11:34:15 +00:00
|
|
|
dm_audit_log_ctr(DM_MSG_PREFIX, ti, 1);
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
bad:
|
2019-07-18 00:46:15 +00:00
|
|
|
|
|
|
|
verity_verify_sig_opts_cleanup(&verify_args);
|
2023-03-01 11:34:15 +00:00
|
|
|
dm_audit_log_ctr(DM_MSG_PREFIX, ti, 0);
|
2012-03-28 17:43:38 +00:00
|
|
|
verity_dtr(ti);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2022-09-07 20:30:58 +00:00
|
|
|
/*
|
|
|
|
* Get the verity mode (error behavior) of a verity target.
|
|
|
|
*
|
|
|
|
* Returns the verity mode of the target, or -EINVAL if 'ti' is not a verity
|
|
|
|
* target.
|
|
|
|
*/
|
|
|
|
int dm_verity_get_mode(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
|
|
|
|
if (!dm_is_verity_target(ti))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return v->mode;
|
|
|
|
}
|
|
|
|
|
2022-06-27 15:35:24 +00:00
|
|
|
/*
|
|
|
|
* Get the root digest of a verity target.
|
|
|
|
*
|
|
|
|
* Returns a copy of the root digest, the caller is responsible for
|
|
|
|
* freeing the memory of the digest.
|
|
|
|
*/
|
|
|
|
int dm_verity_get_root_digest(struct dm_target *ti, u8 **root_digest, unsigned int *digest_size)
|
|
|
|
{
|
|
|
|
struct dm_verity *v = ti->private;
|
|
|
|
|
|
|
|
if (!dm_is_verity_target(ti))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
*root_digest = kmemdup(v->root_digest, v->digest_size, GFP_KERNEL);
|
|
|
|
if (*root_digest == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
*digest_size = v->digest_size;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
#ifdef CONFIG_SECURITY
|
|
|
|
|
|
|
|
#ifdef CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG
|
|
|
|
|
|
|
|
static int verity_security_set_signature(struct block_device *bdev,
|
|
|
|
struct dm_verity *v)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* if the dm-verity target is unsigned, v->root_digest_sig will
|
|
|
|
* be NULL, and the hook call is still required to let LSMs mark
|
|
|
|
* the device as unsigned. This information is crucial for LSMs to
|
|
|
|
* block operations such as execution on unsigned files
|
|
|
|
*/
|
|
|
|
return security_bdev_setintegrity(bdev,
|
|
|
|
LSM_INT_DMVERITY_SIG_VALID,
|
|
|
|
v->root_digest_sig,
|
|
|
|
v->sig_size);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static inline int verity_security_set_signature(struct block_device *bdev,
|
|
|
|
struct dm_verity *v)
|
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Expose verity target's root hash and signature data to LSMs before resume.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, or -ENOMEM if the system is out of memory.
|
|
|
|
*/
|
|
|
|
static int verity_preresume(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct block_device *bdev;
|
|
|
|
struct dm_verity_digest root_digest;
|
|
|
|
struct dm_verity *v;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
v = ti->private;
|
|
|
|
bdev = dm_disk(dm_table_get_md(ti->table))->part0;
|
|
|
|
root_digest.digest = v->root_digest;
|
|
|
|
root_digest.digest_len = v->digest_size;
|
|
|
|
if (static_branch_unlikely(&ahash_enabled) && !v->shash_tfm)
|
|
|
|
root_digest.alg = crypto_ahash_alg_name(v->ahash_tfm);
|
|
|
|
else
|
|
|
|
root_digest.alg = crypto_shash_alg_name(v->shash_tfm);
|
|
|
|
|
|
|
|
r = security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_ROOTHASH, &root_digest,
|
|
|
|
sizeof(root_digest));
|
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = verity_security_set_signature(bdev, v);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
bad:
|
|
|
|
|
|
|
|
security_bdev_setintegrity(bdev, LSM_INT_DMVERITY_ROOTHASH, NULL, 0);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* CONFIG_SECURITY */
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
static struct target_type verity_target = {
|
|
|
|
.name = "verity",
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
/* Note: the LSMs depend on the singleton and immutable features */
|
2024-01-30 22:37:00 +00:00
|
|
|
.features = DM_TARGET_SINGLETON | DM_TARGET_IMMUTABLE,
|
2024-02-20 18:32:52 +00:00
|
|
|
.version = {1, 10, 0},
|
2012-03-28 17:43:38 +00:00
|
|
|
.module = THIS_MODULE,
|
|
|
|
.ctr = verity_ctr,
|
|
|
|
.dtr = verity_dtr,
|
|
|
|
.map = verity_map,
|
|
|
|
.status = verity_status,
|
2015-10-15 12:10:50 +00:00
|
|
|
.prepare_ioctl = verity_prepare_ioctl,
|
2012-03-28 17:43:38 +00:00
|
|
|
.iterate_devices = verity_iterate_devices,
|
|
|
|
.io_hints = verity_io_hints,
|
dm-verity: expose root hash digest and signature data to LSMs
dm-verity provides a strong guarantee of a block device's integrity. As
a generic way to check the integrity of a block device, it provides
those integrity guarantees to its higher layers, including the filesystem
level.
However, critical security metadata like the dm-verity roothash and its
signing information are not easily accessible to the LSMs.
To address this limitation, this patch introduces a mechanism to store
and manage these essential security details within a newly added LSM blob
in the block_device structure.
This addition allows LSMs to make access control decisions on the integrity
data stored within the block_device, enabling more flexible security
policies. For instance, LSMs can now revoke access to dm-verity devices
based on their roothashes, ensuring that only authorized and verified
content is accessible. Additionally, LSMs can enforce policies to only
allow files from dm-verity devices that have a valid digital signature to
execute, effectively blocking any unsigned files from execution, thus
enhancing security against unauthorized modifications.
The patch includes new hook calls, `security_bdev_setintegrity()`, in
dm-verity to expose the dm-verity roothash and the roothash signature to
LSMs via preresume() callback. By using the preresume() callback, it
ensures that the security metadata is consistently in sync with the
metadata of the dm-verity target in the current active mapping table.
The hook calls are depended on CONFIG_SECURITY.
Signed-off-by: Deven Bowers <deven.desai@linux.microsoft.com>
Signed-off-by: Fan Wu <wufan@linux.microsoft.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
[PM: moved sig_size field as discussed]
Signed-off-by: Paul Moore <paul@paul-moore.com>
2024-08-03 06:08:26 +00:00
|
|
|
#ifdef CONFIG_SECURITY
|
|
|
|
.preresume = verity_preresume,
|
|
|
|
#endif /* CONFIG_SECURITY */
|
2012-03-28 17:43:38 +00:00
|
|
|
};
|
2023-04-09 16:43:37 +00:00
|
|
|
module_dm(verity);
|
2012-03-28 17:43:38 +00:00
|
|
|
|
2024-07-04 14:09:57 +00:00
|
|
|
/*
|
|
|
|
* Check whether a DM target is a verity target.
|
|
|
|
*/
|
|
|
|
bool dm_is_verity_target(struct dm_target *ti)
|
|
|
|
{
|
|
|
|
return ti->type == &verity_target;
|
|
|
|
}
|
|
|
|
|
2012-03-28 17:43:38 +00:00
|
|
|
MODULE_AUTHOR("Mikulas Patocka <mpatocka@redhat.com>");
|
|
|
|
MODULE_AUTHOR("Mandeep Baines <msb@chromium.org>");
|
|
|
|
MODULE_AUTHOR("Will Drewry <wad@chromium.org>");
|
|
|
|
MODULE_DESCRIPTION(DM_NAME " target for transparent disk integrity checking");
|
|
|
|
MODULE_LICENSE("GPL");
|