sev
本文是对1的高仿，但是劣质版本，非常建议去阅读下huangyong的文章
背景
在云环境中有两类角色:
- platform owner : 云厂商
- guest owner : 租用云厂商的用户
云厂商负责提供云基础设施, 为用户构建出一套”属于自己的” 计算存储网络， 同时需要保证云基础设施足够优质来吸引用户。
而租户则是使用云厂商提供的云基础设施，来跑自己的业务，在云场景下， 租户只需要关心云环境中的业务，而无需关心云基础设施的层面的问题， 例如: 云主机的网络波动，硬件老化等等。
而云环境下的安全也是platform owner的一个重要服务，而，只能选择信任 云厂商提供的安全防护功能。但是, 总有防不住的时候，一旦platform owner的 的防线被击穿，其上面运行的guest都会有风险，而由于host有足够的权限，并且 其操作对于guest而言都是透明的，所以对于一些数据敏感的guest owner而言， 这种安全风险不能接受。
前面也提到, platform owner 也想提供更优质的服务来吸引用户。而安全防护也是 一个很重要的服务。但是软件防护总是限制的, 而能不能通过在硬件层面来保证， 在host 安全组件被击破后，还有一道硬件防线，可以防止guest不被攻击。AMD SEV 提供了该解决方案。
简单来说，AMD SEV 主要提供了一个隔离方案，让host无法观测到guest的行为， 同时提供给 guest 一些接口，可以让 guest 来验证，自己是跑在一个安全的 AMD SEV 环境。
另外, 对于提供sev功能的云厂商来说，既希望提供给用户这个功能，也希望 能像传统虚拟机一样管理sev虚拟机的生命周期. 例如:
- 启动
- 关闭
- 迁移
- 快照
overflow
在介绍SEV之前, 我们先来看下传统虚拟机。
在传统架构中，有两个角色, Hypervisor和guest, Hypervisor, 几乎可以 访问虚拟机所有的位置的数据，还可以修改虚拟机运行上下文:
- MEMORY
- REGISTER
- DISK
所以，在SEV中, 就是要限制Hypervisor的权限，不能让host随意获取到guest 中运行的数据，甚至不能恶意模块修改. 而最直接的方法就是数据加密， 关于这部分我们在SME 章节中介绍
另外, guest需要一种方法可以确认，自己所处的环境是一个安全的，可以 被信任的环境。AMD是通过证书链认证实现的，这部分内容我们在证书链 章节中介绍。
hypervisor 负责管理guest的生命周期，资源分配. 而由于sev引入了证书链， 所以需要host管理各种证书. 并且sev又引入了一些其他对guest管理的额外 要求，这都需要hypervisor 与 sev 安全组件交互，所以需要一组API，以及 需要定义使用这些API的通道. 这些内容我们放到API章节中介绍, 并且在该章节 中，我们会介绍部分API，以及其在SEV 框架中的作用。
SME
Secure Encrypted Virtualization (SEV) 功能允许在VM运行期间，透明的 加解密内存，并且每个VM加解密时，可以使用他们独有的key(密钥)。实现方式 是在memory control 中实现一个高性能的加密模块，该加密模块可以编程多个密钥， 用来给不同的虚拟机使用。
TIPS
我们来思考下，memory control 如何识别本次访问是属于哪个虚拟机呢?
AMD的做法是，在对TLB虚拟化时，通过引入ASID, 可以标记该虚拟机拥有哪些 TLB, 从而让TLB中可以拥有虚拟机维度的TLB隔离。SEV功能也是复用了ASID， 让其作为密钥ID。
在AMD后续的实现中，除了对内存加密外，还实现了其他额外的功能:
- SEV-ES : 寄存器加密
- SEV-SNP : 将host和guest内存隔离
TODO
证书链
上面提到，虽然guest可以感知到自己的内存是加密的，但是如何保证hypervisor 不能解 密呢? 换句话说，guest在一个对外完全封闭，对内四处漏风的环境内如何验证自己的 环境符合一定的安全需求。
举个例子, 我们去买一个手机, 手机厂家说, 这手机遥遥领先, 满载跑起来温度不超过50度。 作为聪明的消费者, 我们当然不信，于是我们打开B站权威（没有收钱）的up主的评测, 去 验证手机厂家说的话是否属实。
而guest就像是消费者，云厂商中的基础设施就像是手机厂家, 其几乎不信任基础设置中 的任何组件。所以，需要有一个权威机构保证某个东西完全没有问题，这样guest可以 完全信任该组件。并无忧无虑的和其通信。
上图是SEV架构下，guest 信任者的示例图，在上图中, guest 除了AMD hardware and Firmware 谁都不信。而AMD hardware and Firmware作为最底层的硬件, 而且用户对其足够信任(如果不信任, 就不会买了), guest将其做为唯一的信任者, 这很合理，但是这又是很理想的情况。为什么呢? 需要大家思考几个问题:
- guest如何知道自己运行的环境就是`AMD`牌子的`haredware and Firmware`, 而不是`DMA`牌.
- 在guest中，会有一些行为需要和sev fw 进行通信。但是理论上，从guest出发的所有行为， hypervisor都能捕获，guest如何在穿过hypervisor的情况下，和 sev fw建立起安全的通信通道
SEV通过证书链机制，实现上面的需求，我们来看下具体的细节
keys and certificate
在整个的证书链中，包含很多的keys，这些key之间存在一个认证链，我们先把 整个关系展示出来，在分别介绍:
ASK, ARK:
ask 是amd的信任根，其签名表示AMD的真实性. 使用ARK私钥对ASM公钥进行签名. ark 是一个中级密钥，使用ask私钥对cek进行签名.
- CEK
:
cek 用来对pek进行签名，从而将pek锚定到amd的信任根, 每个芯片都有一个唯一的 cek，关于该密钥km spec中的描述如下:
1 2 3
Each chip has a unique CEK which is derived from secrets stored in chip-unique OTP fuses. The lifetime of this key is the lifetime of the individual chip.
OTP 熔丝是一种硬件技术，用于在芯片制造过程中或之后存储永久性数据。这种数据一 旦写入，就无法修改或删除，因此可以用于生成独特的、不可复制的密钥。这种机制确 保了每个芯片的 CEK 是唯一的，并为芯片的安全功能提供了一个信任基础。
所以, 将CEK公私钥封装到芯片内部，同时，又使用ASK私钥对CEK公钥签名生成证书，保存在 AMD厂商，这样就相当于把该机器锚定了amd的信任链. 所以, CEK 是固件可信的起点(回答了第一个疑问)那怎么验证cek是否有效呢??
可以让硬件对使用cek私钥另一个公钥进行签名，生成证书，然后，使用厂商的cek证书中的公 钥对其签署的证书，进行验签，如果验签成功，说明CEK没有问题，同时也能说明CEK签署的证书 也没有问题。
那签署的是什么证书？有何作用?
PEK, PDH:
PEK 是由固件创建，由CEK和OCA(下面介绍) 双签名，其作用是对PDH进行签名。
PDH 使用椭圆曲线Diffie-Hellman(ECDH)算法密钥。PDH主要用于SEV fw和其他外部实体（guest owner) 协商一个住密钥，然后使用这个主密钥通过 key derivation function(KDF) 来建立起一个可信通道。
所以，使用该可信通道，就可以让Guest和set fw在穿过hypervisor的情况下， 安全的通信OCA:
OCA证书是自签署的, OCA私钥用来签名PEK, 用来表明PEK是经过platform owner签署的. 该OCA密钥对以及证书生成的方式，我们放到下面的章节中介绍
API
对这些密钥的管理，以及vmm和guest VM memory 之间的安全数据的传输，是通 过处理器中的SEV firmware处理。host hyperivor 和 sev fw之间通信是通过 一些API3.
同时guest有时需要外部能访问到非加密数据, 例如DMA，所以在guest中，某些 memory operation 是不需要使用key加密的。如下图所示:
在上图中，guest可以控制页表的c-bit来控制哪些页在访问时, 需要被加解密. 在sev-snp中，这个行为会更复杂，我们先不关注。总之，driver 可以使用API 来管理key，但是获取不到guest key。而运行在guest时，则会使用guest key 在访存操作时，进行数据加解密。
所以, 软件如果要配置 sev 功能，需要通过 sev 提供的一组API。
API包括:
Platform Management API: 用于platform owner配置平台和查询平台范围内的数据
Guest Management API: 在整个客户机生命周期中管理
Guest Context
而SEV driver 通过SEV fw给定的方式, 向fw发送命令请求。目前支持两种通信方式:
- Mailbox mode: 最初的固件
- Ring Buffer Mode: 0.24+ 固件
其中, Mailbox Mode是通过MMIO Register实现，而Ring Buffer Mode而是在内存中 划定了一块ringbuffer，需要先通过 Mailbox方式下发 RING_BUFFER 命令进入。
Platform Management API
overview
Platform Context
SEV fw 在 platform 的整个生命周期中维护了一个platform context. 该context包含了 SEV API 所需的data 和 metadata.
PlatForm Context (PCTX) Field:
PCTX中主要包括:
platform state
某些API会改变platform state. 并且某些API只能在特定的state下才能执行。并且 Guest Management API 只能在INIT/WORKING platform states 下，才能执行:
- platform config
- keys: PDH, PEK, CEK, OCA。这些key有些是导入的，有些是生成的， 有些是固化在固件中的。platform API 负责去管理这些证书的生命周期.
- Guest Information:
- guest count
- guest contexts
Ownership
一个platform 可能由外部实体拥有，也可能是self-owned。platform owner的所有权由一个以 OCA（所有者信任根）为根的证书链定义。OCA 签署 PEK。当platform不由外部实体拥有时， platform会生成自己的 OCA 密钥对.
这有什么用呢?
下面是自己的理解。很可能不对。
目前在整个AMD的信任链中，PSP(Platform Secure Processor) 是根据CET有一套完整的信任链。 但是, Processor 之上的软硬件组件，还是需要platform 来保证. 虽然platform owner已经无法 窥探到guest的真面目了, 但是作为guest owner来说，还是想要platform owner的一些其他的服务 和特性。
举个不恰当的例子。某用户最近想买 aliyun deepseek 一体机. 但是买不起一手的，只能买二手的。 去闲鱼上一看, 我的天，这些同样牌子的aliyun deepseek 一体机，怎么长得都不一样。用户也 不确定自己买回来的是真的 aliyun牌子的还是awaiyun的。
那用户就可以通过OCA验证。设备再aliyun出厂时，导入了OCA的公钥。以及使用了OCA私钥，签署了 PEK。这样用户就可以去做验证了。
当然，如果客户不想买一体机，想买个裸机回来自己搭建，那platform owner就是他自己。这时， OCA就可以使用sev fw API 在这台机器生成。
所以，总结来说，OCA就是用来验证platform owner的身份的真伪。
Non-volatile Storage
上面提到的PCTX某些信息的生命周期可能比物理机运行周期还长（关机不清除) 。所以，这些信息 是存储在non-volatile storage中。包括:
- PDH key pair
- PDH certificate
- PEK key pair
- PEK certificate
- OCA public key
- OCA private key (only if self-owned)
- OCA certificate
这些cert/key 在生成导入后，立即加密存储.