Matrix

实验 测试发现period_size=512或者256时均不发生丢包，于是做以下实验： sampling rate channel bit depth period_size package size 是否丢包 48k 2 16bit 1024 4096Byte 丢包 48k 1 16bit 1024 2048Byte 丢包 48k 2 16bit 512 2048Byte 不丢包 48k 4 16bit 512 4096Byte 不丢包 通过实验发现，丢包与period_size相关与package size无关。 通过perf top分析 通过perf top查看系统和aplay中哪些函数占比高: 这里可以看到有大量的spin_lock函数占用比较高的cpu时间。猜测系统哪里可能有自旋锁使用不当。但是这里无法看到函数调用栈，不知道哪里调用的spinlock占用cpu资源多。 通过火焰图分析 查看ftrace 123456789101112131415mount -t debugfs none /sys/kernel/debug/c ...

AES AES（Advanced Encryption Standard），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES。其密钥长度则可以是128，192或256比特。 SubBytes：通过一个非线性的替换函数，用查找表(S-Box)的方式把每个字节替换成对应的字节。 ShiftRows：将矩阵中的每个横列进行循环式移位。 MixColumns：每一列的四个字节通过线性变换互相结合得到新的4字节值. AddRoundKey：将输入与轮密钥进行XOR。 以上就是AES加密中的一轮，不同密钥长度进行的轮数不同，128位10轮，192位12轮，256位14轮。 下面具体分析每一步 SubBytes 从一张拥有256个值的替换表(S-Box)中找出对应的值替换。S-Box是固定的，查找公式也是固定。具体可参见Rijndael S-box。用此步骤混淆了输入内容。 ShiftRows 上一步处理后将16个字节分为4组，每组4字节。以字节位单位进行乱序处理，这种打乱是有规律的。如上图中输入第一组第一个字节移动到输出第一组第一个字 ...

目的 安全启动的根本目的是为了防止消费者从软硬件层面对产品的部分关键系统进行读写、调试等高权限的操作。以限制消费者的能力，来达到保护产品的商业机密、知识产权等厂家权益的目的。当然，厂家是不会这样宣传 Secure Boot 的。他们的文案通常都是通过这项技术保护用户的隐私，防止恶意软件修改系统软硬件等等。 可以说，Secure Boot 的安全模型建立在消费者是攻击者这一假设上。消费者在物理上拥有产品硬件，可以对产品进行物理连接、拆机、改装等等物理上的操作，比较专业的消费者甚至可以使用数字示波器监听 CPU 和 RAM 、eMMC 之间的数据传输来读取非常底层的数据传输。可以说跟传统的安全模型中的攻击者相比根本不在一个层面上。 消费者作为攻击者的目的，一般常见的有刷机安装自定义的操作系统（Mod）、绕过厂家封闭的支付平台（IAP）和应用商城安装自定义的应用程序、绕过版权保护系统（DRM）达到复制厂家保护的数字产品内容等等。这些操作往往都会直接影响厂家的利益，因此需要一种能抵抗消费者攻击的安全机制。 而且像 eMMC 这种芯片通常都是业界标准化的，攻击者甚至可以把芯片拆下来，然 ...

TEE软件框架 TEE 系统软件从整体上包含 REE 和 TEE 两部分，各自对应的基础组件如下图所示。 REE 部分 Client Applications（CA） 一般是指指纹录入，支付应用等上层应用，其通过调用 TEE Client API 接口来与 TEE 环境的 Trusted OS 进行交互，这里的 TEE Client API 包括 TEE 厂商自定义的一些接口或 GlobalPlatform（GP） 全球组织定义的通用 API，其目的是制定一套标准的编程接口，方便开发者在不同软硬件平台下使用同一套代码实现其功能。 TEE Client API 通过 ioctl 系统调用对 TEE Driver 进行操作，TEE Driver 是沟通 REE 和 TEE 的桥梁，其通过 SMC 指令，实现将上层的 OpenSession，InvokeCommand，CloseSession 等标准调用的请求转发到 TEE 环境，同时其也会处理来自 TEE 的请求，将请求转发到 TEE Helper Daemon 让其处理。 TEE Helper Daemon 是一个辅助进程，用于 T ...

信息安全 信息安全的三个基本目标是机密性，完整性和可用性。 机密性意味着只有授权实体才能阅读和理解保密的信息。没有访问权限的其他人无法阅读或理解机密信息； 完整性意味着能够确保信息受到保护，以防止未经授权的更改，修改或删除。信息的完整性包括使用识别和认证等方法的起源，完整性和正确性； 可用性意味着信息始终可供授权用户使用。 RPMB简介 RPMB是Replay Protected Memory Block(重放保护内存块)的简称，是eMMC中的一个具有安全特性的分区。此功能使设备能够将数据存储在经过身份验证并防止重放攻击的小型特定区域(通常是4M Bytes)中。这里涉及一个概念Replay Attack和Replay Protected。 Replay Attack(重放攻击) A向B请求服务(比如说登录某个网站)，A将密码hash化传给B。但是在这中间，E抓取到该hash值。此后，E冒充A向B发送同样的hash值来获取服务。 Replay Protected(重放保护) 加随机数。该方法优点是认证双方不需要时间同步，双方记住使用过的随机数，如发现报文中有以前使用过的随机数 ...

TrustZone 如何区分当前访问状态是安全状态下的访问还是非安全状态下的访问？ CPU发出的地址都是虚拟地址，需要经过页表转换才能得到物理地址，其中在pte页表中低12bit（针对4k大小的页表）为控制位，用来控制页表的访问属性，也就是说在页表建立的时候就确定了访问状态是安全状态还是非安全状态，其pte低12bit如下： 这里的bit 5 NS bit（Non-secure bit）：用来指定访问的内存地址是安全映射的还是非安全映射的。 只有当ARM核处于安全状态（NS bit=0）时发送到系统总线（AXI）上的读写操作才会被识别为安全读写操作，对应TEE侧的数据资源才能被访问。反之，当ARM核处于非安全状态（NS bit=1）时，ARM核发送到系统总线上的读写操作请求会被作为非安全读写操作，安全组件会根据对资源的访问权限配置来决定是否响应该访问请求。 💡 NS bit的设置是通过SMC指令触发异常进入EL3安全监视器中设置的，即Normal World通过SMC调用进入Security World，将NS bit置0，Security World通过SMC指令进入Norm ...

安装 hexo 12345npm install hexo-cli -ghexo init blogcd blognpm installhexo server 安装依赖 1234567891011121314151617181920212223242526272829303132333435# 使用 pandoc 渲染器npm un hexo-renderer-markednpm i hexo-renderer-pandocnpm un hexo-renderer-pandocnpm i hexo-renderer-markdown-it-plusnpm install hexo-deployer-gitsudo apt-get install pandocnpm install prism# rssnpm install hexo-generator-feed# butterflynpm install badge-makernpm install --save hexo-renderer-jade hexo-generator-feed hexo-generator-sitemap ...

基础配置 本人是安装的OMV，服务基本上全是docker，而且安装的服务很多中间踩了一些坑，这里记录一下，如果有后来人有幸看到可以避免少踩一些坑： 关于raid磁盘阵列，emmm本人不喜欢用raid，使用的basic模式，主要是为了便于插入到我的服务器上使用，关于数据安全，比较重要的文档笔记我会挂在一个网盘的sync目录下，在nas和网盘中双备份而非备份到两块硬盘里。至于几十G的一部电影，小姐姐什么的丢就丢了吧，不心疼。再次声明一个基本原则，选个大一点的网盘备份自己的重要资料，你要坚信并深信他跑路的可能性远远低于你搞坏nas的概率。 docker image路径问题：本人自用的是绿联DX4600，刷的OMV系统，系统刷到内部32G EMMC中，这个空间是比较小的，默认docker image会下载到/var/lib/docker/目录这个目录显然是挂载在EMMC中的。32G的空间是绝不能满足我的要求的，本人Docker服务安装了几十个，因此需要将该路径切换到其他磁盘路径，建议是搞个ssd，装到ssd里。 一定要采用docker compose部署服务，因为迁移起来非常简单，我从ugo ...

修改UAC配置参数后无法正常通信 如果修改了UAC的配置后出现UAC无法正常通信的问题，可以通过修改设备的idVendor和idProduct来解决，只有设备的idVendor和idProduct发生改变Windows才会重新读取设备的配置描述符。 Kernel 5.4内核配置某些参数后UAC通信异常 例如在44100采样率、4channel、32bit参数下Device到Host端通信异常，而Host端到Device端通信正常。 问题的原因是由于Linux的UAC驱动计算的每次传输的usb包大小不正确，导致USB传输格式不匹配出现了通信异常。详细原因如下： 该参数下每秒钟的数据量为44100 * 4 * 4 = 705600 USB每秒传输一千个包，则每个包的大小为 705600 / 1000 = 705.6 Linux下UAC驱动的做法是每次传输705字节数据，当余数足够多的时候传输705+16=721字节，然后依次循环下去。但是这种方式存在一个问题就是705不是frames大小的整数倍，即705 / (4 * 4) = 44.0625,那么USB每次传输的数据不能完全送到声卡 ...

USB sof统计方法 打时间戳方式 ktime_get_raw_ns() Linux标准接口。 meson_timestamp() Amlogic实现的硬件定时器接口。 sof打时间戳的时机 直接在SOF中断handle里打时间戳，然后将其保存到一个fifo里。 通过一个hrtimer，主动查询SOF中断寄存器查看是否有SOF包，如果有SOF包则打上时间戳保存到fifo里。 sof时间戳导出到应用层 通过seq file创建一个proc（/proc/sof_ts）文件，应用通过读取该文件来获取sof时间戳。 USB sof统计数据方案验证 中断handle里用ktime_get_raw_ns()打时间戳统计数据 数据： | 样本数量 | 平均值（ns） | 最小值（ns） | 最大值（ns） | 方差 | 标准差 | | --- | --- | --- | --- | --- | --- | | 8192 | 125001.0327 | 94125 | 156125 | 2281694.791 | 1510.5279 | sof间隔图表： 统计直方图(124-126us) ...