工具/软件：Linux
您好！
我正在使用 AM5728 Sitara 处理器开发强制电路板。
我使用 了与内核4.4.4.41相对应的 TI SDK PROCESSOR-SDK-LINUX-03.03.00。
我参考了 OMAP-AES_DRIVER.ko。 我已将该模块编译为可加载模块。
此驱动程序由 OMAP-AES.c 和 OMAP-AES-GCM.c 两个文件组成
首先：如果我使用本模块的原始版本，在卸下模块并重新装入时，不进行任何修改，则会出现错误：
用户@cl-debian-armhf：~$ lsmod | grep OMAP-AES_DRIVER
OMAP-AES_DRIVER 19230 0
用户@cl-debian-armhf：~$ sudo modprobe -r -v omap_AES_driver
rmmod OMAP-AES_DRIVER
用户@cl-debian-armhf：~$ lsmod | grep OMAP-AES_DRIVER
用户@cl-debian-armhf：~$ sudo modprobe -v omap_AES_driver
insmod /lib/modules/4.4.41-cl-som-am57x-ti-3.2-patch-by-hand/kernel/drivers/crypto/omap-aes-driver.ko
用户@cl-debian-armhf：~$
用户@cl-debian-armhf：~$ lsmod | grep OMAP-AES_DRIVER
OMAP-AES_DRIVER 19230 0
用户@cl-debian-armhf：~$ sudo tail -n 30 /var/log/syslog
5月 5日10：21：42 cl-debian-armhf 内核：[117.342501] R9：ec886308 R8：13779d1c r7：00000000 R6：eea6d844 R5：bf2e23cc R4：eea6d810
5月 5日10：21：42 cl-debian-armhf 内核：[117.350321] [ ](__driver_attach)从[ ](BUS_TO_EASE_DEV_0x70/0xa4)
5月 5日10：21：42 cl-debian-armhf 内核：[117.358531] r7：00000000 R6：c03f98cc R5：bf2e23cc R4：00000000
5月 5 10：21：42 cl-debian-armhf 内核：[117.364249][ ](bus_for_each_dev)、来自[ ](DRIVER_ATT+0x24/0x28)
5月 5日10：21：42 cl-debian-armhf 内核：[117.372284] R6：c096aa70 R5：ed8e7a00 R4：bf2e23cc
5月 5日10：21：42 cl-debian-armhf 内核：[117.376949] [ ](driver_attach)从[ ](BUS_ADD_DRIVER+0x1a8/0x220)
5月 5日10：21：42 cl-debian-armhf 内核：[117.384991][ ](BUS_ADD_DRIVER)从[ ](DRIVER_REGISTER+0x80/0x100)
5月 5日10：21：42 cl-debian-armhf 内核：[117.393112] r7：ec886d80 R6：c0941760 R5：bf2e5000 R4：bf2e23cc
5月 5日10：21：42 cl-debian-armhf 内核：[117.398827] [ ](driver_register)、从[ ](__platform_driver_register+0x48/0x50)
5月 5日10：21：42 cl-debian-armhf 内核：[117.407908] R5：bf2e5000 R4：c096aa70
5月 5日10：21：42 cl-debian-armhf 内核：[117.41152][ ](__platform_driver_register)、来自[ ](OMAP_AES_DRIVER_INIT+0x1c/0x24 [OMAP_AES_DRIVER])
5月 5日10：21：42 cl-debian-armhf 内核：[ 117.422608] R5：bf2e5000 R4：c0941760
5月 5日10：21：42 cl-debian-armhf 内核：[117.426222] [ ](OMA_AES_DRIVER_INIT [OMAP_AES_DRIVER])、来自[ ](do_one _initcall+0x98/0x1e4)
5月 5 10：21：42 cl-debian-armhf 内核：[117.43644] [ ](多个_initcall)、来自[ ](DO_INIT_MODULE+0x68/0x38c)
5月 5日10：21：42 cl-debian-armhf 内核：[ 117.444566] r10：bf2e2a40 r9：ec886308 r8：13779d1c r7：00000001 r6：ec8863c0 r5：00000001
5月 5日10：21：42 cl-debian-armhf 内核：[117.452467] R4：bf2e2a40
5月 5 10：21：42 cl-debian-armhf 内核：[117.455021] [ ](DO_INIT_MODULE)从[ ](LOAD_MODULE+0x1e28/0x20d8)
5月 5日10：21：42 cl-debian-armhf 内核：[117.463056] R6：ec886300 R5：00000001 R4：eca59f44
5月 5日10：21：42 cl-debian-armhf 内核：[117.467718][ ](LOAD_MODULE)从[ ](SYS_FINIT_MODULE+0x88/0x98)
5月 5日10：21：42 cl-debian-armhf 内核：[117.475578] R10：00000000 R9：eca58000 R8：c000fb44 r7：0000017b R6：7f5b4e80 R5：00000003
5月 5 10：21：42 cl-debian-armhf 内核：[117.483480] R4：00000000
5月 5 10：21：42 cl-debian-armhf 内核：[117.486033] [ ](sys_finIT_module)从[ ](RET_FAST_SYSCALL+0x0/0x34)
5月 5日10：21：42 cl-debian-armhf 内核：[117.494244] R6：00000000 R5：00040000 R4：bed1e3d0
5月 5日10：21：42 cl-debian-armhf 内核：[117.498937] --[结束跟踪6a80443878e91c62 ]---
5月 5日10：21：42 cl-debian-armhf 内核：[117.503594] OMAP-AES 4b700000.AES：无法创建 sysfs 设备 attrs
5月 5日10：21：42 cl-debian-armhf 内核：[117.510189] OMAP-AES 4b700000.AES：初始化失败。
5月 5日10：21：42 cl-debian-armhf 内核：[117.515656] OMAP-AES：4b700000.AES 的探测器失败、错误-17
5月 5日10：23：36 cl-debian-armhf systemd-timesyncd[381]：间隔/增量/延迟/抖动/漂移256s/-0.001s/0.018s/0.001s/+0ppm
5月 5日10：23：36 cl-debian-armhf rsyslogd-2007：操作'action 17'暂停、下次重试时间为 2017年5月5日10：24：06星期五[请尝试 http://www.rsyslog.com/e/2007 ]
5月 5日10：25：08 cl-debian-armhf rsyslogd-2007：操作'action 17'暂停、下次重试时间为 2017年5月5日10：25：38星期五[请尝试 http://www.rsyslog.com/e/2007 ]
但这不是模块修改后的大问题(在/lib/modules 中复制...) 因为我不使用 modprobe、而是重新启动。
现在、在我的案例中、更重要的问题是在 dm-crypt 模块内的 FDE 上下文中使用 OMAP 驱动程序。
TI SDK 版本4.1中存在一个错误、即使 CBC 模式也无法正常工作、但已在4.4中修复。
现在、我的目标是通过在输入(加密/解码之前)和输出(加密/解码之后)缓冲器/散列列表上添加操作来修改/创建新模式。
我没有解释所有细节，而是为了*test*目的创建了一个虚拟模式：在带有常量缓冲器的 ECB 加密前后添加 XOR。
此模式的优势在于、在两种方式(编码/解码)中、我们具有相同的操作(因为 XOR 相互抵消)。
通常、在对纯文本进行加密和解密后、我们必须检索原始纯文本。
第一次尝试：
我直接(为了增加更少的修改)更改了 ECB 模式。
我的目标不是这次修改 ECB 模式、而是只强制不对齐并观察缓冲区。
需要进行两项主要修改；首先在 OMA_SG_COPY 中：
以下是步骤：
-我们从 in_sg (scatterlist)检索 buf_in (为什么 buf_in 和 buf_out 不存储在 ctx 中的问题？)
-我们在 ctx->c_buf_in 中复制 buf_in (仅用于检查)
-我们将 buf_in 的校验和存储在 ctx->check_buf_Before_ECB 中
－我们继续加密操作
第二个最重要的部分是完成任务函数：
我添加的内容：
-我们再次计算 buf_in 的校验和(查看是否已更改)
-如果校验和不同，我尝试打印 SG 和缓冲区，以了解出现了什么问题
然后我们将 buf_out 复制到 dd->out_sg 中(如原始代码中所示)
LUKS 测试
===========
我创建一个具有 ECB 模式的容器，仅用于测试目的：
1) 1)创建带有 dd 的文件容器
2) luksFormat
3) lucksOpen
4) mkfs.ext4
5) 5)安装
6)容器已打开
结果如下：
首先、有时在使用 CO-pro 进行 ECB 加密之前和之后、buf_in cheksum 是不同的。
当我们在加密后比较 c_buf_in 和 buf_in 的实际内容时、会确认此观察结果。
但我注意到容器已打开并正常工作。
那么问题是什么？
问题是，如果 buf_in 在时间上不包含正确的明文，我如何信任它的进一步操作？ (例如 XOR)
其他意见：
在加密前后，我使用 XOR 尝试了*test*模式，方法有两种：
1)强制复制从 SG 到 buf 并使用缓冲区而不是 SG
-> 这不起作用、就像纯文本被随机更改一样。
2) 2)通过使用 XOR_SG 函数对 SG 进行监测、我得到的结果与1)相同
我希望我已经足够清楚地帮助您了解问题。
我附上：
－重新载入模块时的错误日志：error_at_omap_driver_reload.log
-原始 OMAP 驱动程序：OMAP-AES.c/h
- ECB 模式的补丁：ECB_Buf_comp.patch
－LUKS 测试的日志：log_ecb_buf_comp.log
谢谢。 e2e.ti.com/.../3733.error_5F00_at_5F00_omap_5F00_driver_5F00_reload.log
