cpu idle实现原理

通过wfi或wfe指令进入low-power-state。在low-power-state下cpu core保持上电状态，但其大部分时钟停止或者进入时钟门限。这意味着core的绝大部分都处于static state，唯一消耗的功率是用于寻找中断唤醒条件的泄漏电流和少量逻辑时钟。进入low-power-state后将暂停当前的工作直到某个中断或event事件发生会退出low-power-state进入正常运行state。

其唤醒wfi或wfe的interrupt或者event请参考《The AArch64 System Level Programmers’ Model 》D1.6 Mechanisms for entering a low-power state

实验

测试发现period_size=512或者256时均不发生丢包，于是做以下实验：

通过实验发现，丢包与period_size相关与package size无关。

AES

AES（Advanced Encryption Standard），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES。其密钥长度则可以是128，192或256比特。

目的

安全启动的根本目的是为了防止消费者从软硬件层面对产品的部分关键系统进行读写、调试等高权限的操作。以限制消费者的能力，来达到保护产品的商业机密、知识产权等厂家权益的目的。当然，厂家是不会这样宣传 Secure Boot 的。他们的文案通常都是通过这项技术保护用户的隐私，防止恶意软件修改系统软硬件等等。

可以说，Secure Boot 的安全模型建立在消费者是攻击者这一假设上。消费者在物理上拥有产品硬件，可以对产品进行物理连接、拆机、改装等等物理上的操作，比较专业的消费者甚至可以使用数字示波器监听 CPU 和 RAM 、eMMC 之间的数据传输来读取非常底层的数据传输。可以说跟传统的安全模型中的攻击者相比根本不在一个层面上。

消费者作为攻击者的目的，一般常见的有刷机安装自定义的操作系统（Mod）、绕过厂家封闭的支付平台（IAP）和应用商城安装自定义的应用程序、绕过版权保护系统（DRM）达到复制厂家保护的数字产品内容等等。这些操作往往都会直接影响厂家的利益，因此需要一种能抵抗消费者攻击的安全机制。

而且像 eMMC 这种芯片通常都是业界标准化的，攻击者甚至可以把芯片拆下来，然后用市面上现成的通用 eMMC 编程工具来读写上面的内容。

Secure Boot 安全机制的原理，就是将最为核心的安全机制整合到最关键的主 CPU 中。因此就算攻击者可以监听电路板上的线路，甚至拆装个别芯片单独调试，也无法破坏 Secure Boot 的安全机制。

TA的安全性

保证TA的安全需要做到三点：

• 唯一性：由设备厂商发布，确保是由设备厂商自己发布的，而不是经过客户自己替换的
• 完整性：除了要保证TA是由设备厂商发布外还需要确保其内容没有经过改动，被用户修改了TA里面的内容
• 保密性：内容经过加密，别人从系统中导出TA固件也无法获取真实的信息，无法解密

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 是一个辅助进程，用于 TEE 请求 REE 的资源。 一般来说，TEE 需要获得存储在 EMMC 的数据文件（例如安全加密文件，TA 可执行镜像文件等），而读写 EMMC 操作需要复杂的内核驱动的支持，显然如果把读写 EMMC 的驱动放到 TEE 侧运行会使软件复杂度会变得很高，因此 REE 需要一个可以访问这些资源的辅助进程支持，这就是 TEE Helper Daemon 的基本功能。TEE Helper Daemon 在软件逻辑实现上比较简单，以 OP-TEE 的 tee-supplicant 辅助进程为例，整体上是一个循环流程: 其首先通过 ioctl 接口查询是否有来自 TEE 的请求，如果没有，则进入睡眠等待状态，等待 TEE Driver 的唤醒信号，当 TEE Driver 收到来自 TEE 的请求后，会唤醒 tee-supplicant 辅助进程，然后根据请求号进行相应处理（读写数据文件，读写 EMMC 设备分区等），最后返回结果到 TEE Driver，完成一次循环，具体实现可参照《OP-TEE 中 tee-supplicant 执行流程》

信息安全

信息安全的三个基本目标是机密性，完整性和可用性。

• 机密性意味着只有授权实体才能阅读和理解保密的信息。没有访问权限的其他人无法阅读或理解机密信息；
• 完整性意味着能够确保信息受到保护，以防止未经授权的更改，修改或删除。信息的完整性包括使用识别和认证等方法的起源，完整性和正确性；
• 可用性意味着信息始终可供授权用户使用。

TrustZone

如何区分当前访问状态是安全状态下的访问还是非安全状态下的访问？

CPU发出的地址都是虚拟地址，需要经过页表转换才能得到物理地址，其中在pte页表中低12bit（针对4k大小的页表）为控制位，用来控制页表的访问属性，也就是说在页表建立的时候就确定了访问状态是安全状态还是非安全状态，其pte低12bit如下：

安装 hexo

1
2
3
4
5

npm install hexo-cli -g
hexo init blog
cd blog
npm install
hexo server

安装依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 使用 pandoc 渲染器
npm un hexo-renderer-marked
npm i hexo-renderer-pandoc

npm un hexo-renderer-pandoc
npm i hexo-renderer-markdown-it-plus

npm install hexo-deployer-git
sudo apt-get install pandoc

npm install prism

# rss
npm install hexo-generator-feed

# butterfly
npm install badge-maker
npm install --save hexo-renderer-jade hexo-generator-feed hexo-generator-sitemap hexo-browsersync hexo-generator-archive
npm install hexo-butterfly-footer-beautify --save

# 页面加密
npm install --save hexo-blog-encrypt

卸载 hexo 默认 markdown 渲染器，安装 pandoc markdown 渲染器。hexo 默认的 markdown 渲染器不支持 Mathjax，不支持插件扩展，不支持 emoji 表情。pandoc markdown 渲染器支持 Mathjax 语法，不仅可以渲染 markdown，还支持 textile，reStructedText 和许多其他格式，仍然不支持 emoji 表情。

此外还有其他 markdown 渲染器，hexo-renderer-markdown-it 支持 Mathjax 语法（支持不太好），支持 Markdown 以及 CommonMark 语法，渲染速度比 hexo-renderer-marked 快，支持插件配置，支持标题带安全的 id 信息，支持脚注（上标，下标，下划线）。 hexo-renderer-markdown-it-plus 支持 Katex 插件并默认启用，默认启用插件列表：markdown-it-emoji，markdown-it-sub，markdown-it-sup，markdown-it-deflist，markdown-it-abbr，markdown-it-footnote，markdown-it-ins，markdown-it-mark，@iktakahiro/markdown-it-katex，markdown-it-toc-and-anchor。

这里要吐槽一下各版本的 markdown 渲染器，对 latex 语法的支持真是一言难尽，pandoc 用了一段时间发现某些特性不支持打算换一个，然后 latex 公式各种崩，😔毁灭吧。

已迁移到notion page，请访问:NAS 有趣的 Docker 推荐

修改UAC配置参数后无法正常通信

如果修改了UAC的配置后出现UAC无法正常通信的问题，可以通过修改设备的idVendor和idProduct来解决，只有设备的idVendor和idProduct发生改变Windows才会重新读取设备的配置描述符。