dm_verify

最新推荐文章于 2023-11-27 14:04:53 发布
最新推荐文章于 2023-11-27 14:04:53 发布
阅读量475 收藏
点赞数 1
分类专栏： android 文章标签： dm_verify

参考https://cloud.tencent.com/developer/article/1054088

Android AVB 分析（十二）嵌入式设备安全中的 dm-verity 简介
洛奇看世界
01-09 2478
上一篇 《Android AVB 分析（十一）bootloader 是如何进行 verify boot 检查的？》 分析了 bootloader 中是如何调用 libavb 函数库验证 vbmeta 和 boot 等分区的。接下来就打算写一篇介绍 dm-verity 原理的文章，然后再写一篇徒手 dm-verity 实践的文章，结果偶然发现了本篇的英文原版。写得太好，我觉得自己完全没有必要再写原理了。由于原文是英文，有些英语不太好的朋友不一定能完全理解。我花了点时间，结合 AI 将英语原文翻译成中文。
android 6.0 dm-verity技术,XZP (AOSP) 關閉dm-verity及/data強制加密
weixin_42718924的博客
06-03 935
從2018/4的AOSP編譯開始，Sony官方開始強制使用dm-verity和/data加密。而這樣會發生什麼問題呢？使用dm-verity會增加安裝Magisk的難度，畢竟這機制是一開機就會驗證是否有修改系統。不裝Magisk就無法root、或是安裝如Xposed等systemless模組。/data強制加密將會導致TWRP無法使用(閃退)，經過XDA大神及本人的實測，關閉/data強制加密後T...
Android 中的dm-verity
热门推荐
u011280717的博客
07-09 4万+
Android 中的Verified Boot之dm-verity之前做了一个Verified Boot模块相关的工作，但是在网上只有找到google的文档和一个nexus的patch。虽然有patch，但在不同版本的代码上实现起来却可能有一些bug，所以特此记录一下debug这个东西的过程。之前debug的过程一直没找到问题，归根到底还是这个原理没搞清楚就下手，所以我分成原理，接口和应用来说明dm
android dm-verity 功能
ee230的专栏
06-16 1万+
Android dm-verity 实现原理深入研究 思维导图： dm-verity 说明：源码基于 SC20 平台 Android5.1 Android dm-verify overview 目录 Android dm-verify overview.. 1 一、原理… 1 与Verified Boot关系… 1 dm-verity. 1 作用分区… 2 二、模
linux安全机制之dm-verity
爱她就要努力
11-27 1823
Dm-verity 是 device-mapper 架构下的一个目标设备类型， 通过它来保障设备或者设备分区的完整性。Dm-verity类型的目标设备有两个底层设备，一个是数据设备(data device), 是用来存储实际数据的，另一个是hash设备(hash device), 用来存储hash数据的，这个是用来校验data device数据的完整性的。
DM-VERITY流程分析
lieye_leaves的专栏
11-22 3266
dm-verity流程分析
static int verity_verify_io(struct dm_verity_io *io) { bool is_zero; struct dm_verity *v = io->v; struct bvec_iter start; unsigned b; struct crypto_wait wait; struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size); for (b = 0; b < io->n_blocks; b++) { int r; sector_t cur_block = io->block + b; struct ahash_request *req = verity_io_hash_req(v, io); if (v->validated_blocks && likely(test_bit(cur_block, v->validated_blocks))) { verity_bv_skip_block(v, io, &io->iter); continue; } r = verity_hash_for_block(v, io, cur_block, verity_io_want_digest(v, io), &is_zero); if (unlikely(r < 0)) return r; if (is_zero) { /* * If we expect a zero block, don't validate, just * return zeros. */ r = verity_for_bv_block(v, io, &io->iter, verity_bv_zero); if (unlikely(r < 0)) return r; continue; } r = verity_hash_init(v, req, &wait); if (unlikely(r < 0)) return r; start = io->iter; r = verity_for_io_block(v, io, &io->iter, &wait); if (unlikely(r < 0)) return r; r = verity_hash_final(v, req, verity_io_real_digest(v, io), &wait); if (unlikely(r < 0)) return r; if (likely(memcmp(verity_io_real_digest(v, io), verity_io_want_digest(v, io), v->digest_size) == 0)) { if (v->validated_blocks) set_bit(cur_block, v->validated_blocks); continue; } else if (verity_fec_decode(v, io, DM_VERITY_BLOCK_TYPE_DATA, cur_block, NULL, &start) == 0) continue; else { if (bio->bi_status) { /* * Error correction failed; Just return error */ return -EIO; } if (verity_handle_err(v, DM_VERITY_BLOCK_TYPE_DATA, cur_block)) return -EIO; } } return 0; } 这里面怎么修改
08-14
static int verity_verify_io(struct dm_verity_io *io) { struct dm_verity *v = io->v; struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size); // 如果是写操作，不进行验证 if (bio_...
static int LoadDmDeviceTable(int fd, const char *devName, DmVerityTarget *target) { int rc; errno_t err; char *parasBuf = NULL; size_t parasTotalSize; struct dm_ioctl *io = NULL; struct dm_target_spec *ts = NULL; char *paras = NULL; FS_DM_RETURN_ERR_IF_NULL(target); FS_DM_RETURN_ERR_IF_NULL(target->paras); parasTotalSize = DM_ALIGN(sizeof(*io) + sizeof(*ts) + target->paras_len + 1); parasBuf = calloc(1, parasTotalSize); if (parasBuf == NULL) { BEGET_LOGE("error, calloc dm table fail"); return -1; } io = (struct dm_ioctl *)parasBuf; ts = (struct dm_target_spec *)(parasBuf + sizeof(*io)); paras = parasBuf + sizeof(*io) + sizeof((*ts)); do { rc = InitDmIo(io, devName); if (rc != 0) { BEGET_LOGE("error 0x%x, init dm io", rc); break; } io->data_size = parasTotalSize; io->data_start = sizeof(*io); io->target_count = 1; // io->flags |= DM_READONLY_FLAG; ts->status = 0; ts->sector_start = target->start; ts->length = target->length; err = strcpy_s(ts->target_type, sizeof(ts->target_type), "verity"); if (err != EOK) { rc = -1; BEGET_LOGE("error 0x%x, cp target type", err); break; } err = strcpy_s(paras, target->paras_len + 1, target->paras); if (err != EOK) { rc = -1; BEGET_LOGE("error 0x%x, cp target paras", err); break; } ts->next = parasTotalSize - sizeof(*io); rc = ioctl(fd, DM_TABLE_LOAD, io); if (rc != 0) { BEGET_LOGE("error 0x%x, DM_TABLE_LOAD failed for %s", rc, devName); break; } } while (0); free(parasBuf); return rc; } static int ActiveDmDevice(int fd, const char *devName) { int rc; struct dm_ioctl io; rc = InitDmIo(&io, devName); if (rc != 0) { return rc; } // io.flags |= DM_READONLY_FLAG; rc = ioctl(fd, DM_DEV_SUSPEND, &io); if (rc != 0) { BEGET_LOGE("error, DM_TABLE_SUSPEND for %s, ret=%d", devName, rc); return rc; } return 0; } 注释以后有没有什么影响
08-14
然而，仅仅去掉只读标志并不能使设备真正可写，因为还需要在底层驱动中支持写入操作（如我们之前讨论的修改verity_map和verity_verify_io函数）。 #### 可能的影响： 1. **允许写入操作**：如果只读标志被移除，...
/* * Bio map function. It allocates dm_verity_io structure and bio vector and * fills them. Then it issues prefetches and the I/O. */ static int verity_map(struct dm_target *ti, struct bio *bio) { struct dm_verity *v = ti->private; struct dm_verity_io *io; bio_set_dev(bio, v->data_dev->bdev); bio->bi_iter.bi_sector = verity_map_sector(v, bio->bi_iter.bi_sector); if (((unsigned)bio->bi_iter.bi_sector | bio_sectors(bio)) & ((1 << (v->data_dev_block_bits - SECTOR_SHIFT)) - 1)) { DMERR_LIMIT("unaligned io"); return DM_MAPIO_KILL; } if (bio_end_sector(bio) >> (v->data_dev_block_bits - SECTOR_SHIFT) > v->data_blocks) { DMERR_LIMIT("io out of range"); return DM_MAPIO_KILL; } if (bio_data_dir(bio) == WRITE) return DM_MAPIO_KILL; io = dm_per_bio_data(bio, ti->per_io_data_size); io->v = v; io->orig_bi_end_io = bio->bi_end_io; io->block = bio->bi_iter.bi_sector >> (v->data_dev_block_bits - SECTOR_SHIFT); io->n_blocks = bio->bi_iter.bi_size >> v->data_dev_block_bits; bio->bi_end_io = verity_end_io; bio->bi_private = io; io->iter = bio->bi_iter; verity_fec_init_io(io); verity_submit_prefetch(v, io); submit_bio_noacct(bio); return DM_MAPIO_SUBMITTED; }
最新发布
08-14
static int verity_verify_io(struct dm_verity_io *io) { struct dm_verity *v = io->v; struct bio *bio = dm_bio_from_per_bio_data(io, v->ti->per_io_data_size); // 关键修改：允许写操作通过 if (bio_...
sys.dm_db_index_operational_stats 举例说明如何使用
05-24
page_verify_failure_count FROM sys.dm_db_index_operational_stats(NULL,NULL,NULL,NULL) WHERE database_id > 4 ``` 2. 查询特定表的操作统计信息： ``` SELECT index_id, page_id, page_type_desc, ...
DM-Verity整体流程
smj15263180896的博客
11-07 1411
2.2.2 sudo veritysetup format A_1_6_gos0-fs_targetfs.img A_1_6_gos0-fs_targetfs.img --data-blocks 5767168 --hash-offset 23622320128 （生成文件data+hash）2.2 进入nv产出包 out_new1 在tii-a 和tii-b 生成加密 A_1_6_gos0-fs_targetfs.img。2.1 制作nv包，获得 A_1_6_gos0-fs_targetfs.img。
dm-verity
weixin_30471065的博客
01-17 544
一、Device Mapper： dm-verity是内核子系统的Device Mapper中的一个子模块，所以在介绍dm-verity之前先要介绍一下Device Mapper的基础知识。 Device Mapper为Linux内核提供了一个从逻辑设备到物理设备的映射框架，通过它，用户可以定制资源的管理策略。当前Linux中的逻辑卷管理器如LVM2（Linux Volume Manager...
深入理解dm-verity机制
whuzm08的专栏
12-27 4万+
近期做的一个项目，由于客户对安全性要求比较高，涉及到文件系统校验的问题，起初是在ramdisk中挂载rootfs后对所有重要的文件检查sha256，但是随着rootfs的逐步增大，发现校验花费的时间太长，竟然达到十几秒，于是就想改用一种方案，首先想到的是整个rootfs校验后在挂载，这样肯定是比一个文件一个文件校验要来得快些，但是项目中用的是nandflash，并不是EMMC，所以文件系统只能采用...
dm-verity原理剖析
内核工匠
09-10 9618
一、技术模块简介Dm-verity 是 device-mapper 架构下的一个目标设备类型， 通过它来保障设备或者设备分区的完整性。Dm-verity类型的目标设备有两个底层设备，一个...
Android Verified Boot dm-verity 优化和实战
求变，从思想开始
05-31 6181
Android O/P 版本以来，谷歌加入了system-as-root的特性，此时ramdisk和system是一起放在同一个system.img镜像中的。而系统起来之后也就不存在system分区了，而是直接把system镜像挂载到/根目录上。那么这个操作是怎么进行的呢？ system.img默认是需要使能dm-verity来挂载的，那么这就涉及到如何使能dm-verity来挂载...
Android安全启动学习（四）：device-mapper-verity (dm-verity)和哈希树
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
10-11 3623
dm-verity是内核子系统的Device Mapper中的一个子模块，所以在介绍dm-verity之前先要介绍一下Device Mapper的基础知识。Device Mapper为Linux内核提供了一个从逻辑设备到物理设备的映射框架，通过它，用户可以定制资源的管理策略。当前Linux中的逻辑卷管理器如LVM2（Linux Volume Manager 2）、EVMS（Enterprise Volume Mageagement System）、dmraid等都是基于该机制实现的。
MTK DM机制讲解
攻城狮
06-08 1243
（一）窗体的重画       通过观察可以发现，每个窗体模板都调用这样一个函数：dm_redraw_category_screen()。这个函数便是显示窗体的函数。它内部的实现是这样的：获得该窗体所包含的组件及它们的属性，再根据组件的类型和属性，调用不同的接口，逐一绘制各组件。详细流程如下图所示：   由上面的流程可见，无论是窗体所包含的组件，还是组件的属性，都是根据模
关于Android9.0 断电后升级问题排查分析
李标标的博客
03-19 1468
最近遇到一个项目Android 9.0的,很多机器出现了开机dm-verify error的错误,排查了很久,做了大量的测试,在此坐下记录分析流程 1.问题复现 2.问题排查 3.问题解决 一.问题复现 起初的信息并不全,升级的log也是全部跑完了,正好过年期间看了下updaer断电后升级的机制,年后重新看这个问题,发现升级的log其实都是retry的,也就是升级中间关机过 测试...
Android Verified Boot 2.0
努力创作有价值的文章
10-12 1万+
AVB2.0简要说明：https://blog.youkuaiyun.com/Thanksgining/article/details/83011651 AVB2.0(Android Verified Boot2.0)是google新设计的verified boot流程用于保护boot/recovery/system/vendor等一些受保护分区的完整性。MTK平台中dtbo不使用AVB2.0保护，buil...
dm-verify和avb
03-24
<think>嗯，用户想了解dm-verify和AVB（Android Verified Boot）的关系以及它们的用法。首先，我需要确定这两个概念各自的定义和作用，然后再看看它们是如何在Android系统中协同工作的。 首先，AVB是Android Verified Boot的缩写，主要用于启动验证，确保设备启动链中每个阶段的固件都是经过验证的，没有被篡改。根据引用[1]中的内容，AVB 2.0的设计中，hashtree验证错误是由HLOS（High-Level Operating System，即Android系统）而不是引导加载程序（bootloader）检测的。这说明AVB在验证过程中涉及到不同的阶段，可能在系统启动的不同环节进行验证。 然后是dm-verify，这是Linux设备映射器（Device Mapper）的一个模块，用于在块设备层进行实时验证。dm-verify通常用于验证整个分区的完整性和真实性，比如系统分区或vendor分区。根据已有的知识，dm-verify会在系统运行时对每个数据块进行验证，确保其未被篡改，这可能与AVB的验证阶段不同，AVB更多是在启动时验证，而dm-verify是在运行时持续验证。 接下来需要理清两者的关系。根据Android文档，AVB和dm-verify可以结合使用。AVB在启动阶段验证内核和initramfs等组件，而dm-verify则在系统启动后对系统分区进行实时验证。引用[2]中提到了启动参数的设置，包括root分区的PARTUUID和文件系统类型，这可能与dm-verify在挂载根文件系统时的验证有关。例如，在启动参数中设置dm-verify相关的参数，确保根文件系统在挂载时进行验证。 在实现方式上，AVB可能通过bootloader传递验证信息给内核，比如通过cmdline参数，而dm-verify则利用这些参数在内核层面进行验证。例如，AVB可能会在启动时生成一个哈希树（hashtree），并将该信息写入vbmeta结构体中，内核在启动时会读取这些信息，并通过dm-verify模块进行持续的验证。 关于具体用法，用户可能需要配置AVB的vbmeta结构体，生成相应的签名，并在设备的分区布局中包含vbmeta分区。同时，在内核配置中启用dm-verify的支持，并在设备树或启动参数中指定验证相关的参数，如dm="..."。这样，在系统启动时，AVB会验证boot和vbmeta分区，而dm-verify在挂载系统分区时进行实时验证。 可能需要注意的问题包括两者的验证阶段不同，AVB在启动早期，而dm-verify在运行时，因此它们的错误处理机制可能不同。例如，引用[1]提到AVB的hashtree_error_mode参数控制如何处理验证错误，而dm-verify可能在内核层面触发不同的错误处理机制，比如重启或进入安全模式。 用户可能的应用场景包括需要高安全性的Android设备，确保从启动到系统运行的每个阶段都经过验证，防止恶意软件或未经授权的修改。此外，了解如何配置和调试这些验证机制，对于系统开发者和安全工程师来说非常重要。 相关问题方面，用户可能还想知道如何配置AVB和dm-verify的具体步骤，如何处理验证失败的情况，以及两者在性能上的影响。此外，可能对如何生成和签名vbmeta镜像，如何集成到系统镜像中，以及如何调试验证过程中的问题感兴趣。</think>### dm-verify与AVB的关系及实现分析 #### 1. **基本概念** - **AVB (Android Verified Boot)**：用于验证启动链的完整性，从bootloader到系统分区的每个阶段均需验证签名[^1]。其核心通过`vbmeta`分区存储哈希值和签名。 - **dm-verify**：Linux内核中的设备映射器模块，用于在块设备层实时验证数据完整性，常与AVB配合保护系统分区[^2]。 #### 2. **协作机制** - **启动阶段**：AVB验证`boot.img`和`vbmeta`分区的签名，确保引导组件可信。 - **运行时验证**：系统启动后，dm-verify通过`vbmeta`中的哈希树（hashtree）实时校验`/system`或`/vendor`分区的每个数据块。 #### 3. **实现配置** ##### AVB配置步骤： 1. 生成密钥对并签名分区镜像： ```bash avbtool make_vbmeta_image --output vbmeta.img --include_descriptors_from_image boot.img ``` 2. 将`vbmeta.img`刷入设备独立分区，并在bootloader中启用AVB验证。 ##### dm-verify启用方法： 在内核配置中启用`CONFIG_DM_VERITY`，并通过启动参数传递验证参数： ``` dm="1 vroot none ro 1, 0 253:0 verity 1 PARTUUID=xxxx... PARTUUID=xxxx... 4096 4096 512 512 sha256 hashtree_hex salt_hex" ``` 参数解析： - `PARTUUID`：指定待验证分区及哈希树所在分区。 - `sha256`：哈希算法类型。 #### 4. **错误处理** - **AVB**：通过`hashtree_error_mode`定义验证失败行为（如`AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE`）[^1]。 - **dm-verify**：触发I/O错误，可能导致挂载失败或内核panic。 #### 5. **典型应用场景** - 防止Rootkit篡改系统分区。 - 满足Android兼容性要求（如GMS认证设备必须启用AVB）。 --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值