回滚设计
RollBack
威胁模型，
系统本身是否可信，
突出多机的问题。
TOCTOU
感知回滚 -> 做出相应，消除状态不一致 -> 达到新的状态
M1交互操作，S1软件执行过程（单机收费软件，不收费，需要输入密码的程序，不需要密码就能使用）
M2交互数据，S2软件附加数据（回滚进行暴力破解）
M3虚拟机状态欺骗，S3软件自身状态
单机和多机旧状态威胁:TOCTOU，S1（这样的状态不能通过回滚到达），M3，S3
旧数据威胁:S2
交互状态威胁：M1 -> M2，
回滚感知->回滚监控域，状态度量，TOCTOU，M3
抗回滚数据域，S2
状态恢复，M1，M2，S1，S
3（通过对内存代码区进行，完整性度量）
状态收集机制
回滚发生前需要收集的状态： 解决回滚对于其他方的透明性
在虚拟机层面回滚回滚的信息是一定能够收集到的
| 自身状态记录 |
回滚感知 |
交互状态验证链 |
| local PCR |
remote PCR |
PCR measurement Chain |
| 传统PCR + rvTPM扩展 |
通过类似mount操作将其他虚拟机的PCR映射到本地（权限） |
通过local或者remoutPCR构造状态交互链。不论是交互的服务，还是单机服务 |
| 回滚策略和以前一样 |
由于是进行映射，回滚之后需要再次确认映射关系 |
交互状态验证在每次回滚恢复之后将被重置到回复完成后的状态 |
自由mount机制（多机的状态交互经常发生改变）利用hypercall实现？，
- 虚拟机的回滚事件，虚拟机的快照版本，rvTPM也需要记录
- 针对抗回滚监控域，监控域的快照版本，监控域的回滚事件，启动时候的状态度量
- 针对抗回滚的数据域，针对多应用提供多组PCR，多数据试图，数据域，使用方的状态记录，操作日志以及其操作度量链
- 数据域，vTPM里面和外面都存在，他们之间的区别？
- 针对跨物理机的情况，回滚通知的传播机制？
- 当跨节点的物理机较多，采用remote PCR挂载（更加准确的状态跟踪）
- 针对云服务的情况
- 交互，自身与外界的交互，通过PCR measurement Chains 完成度量。
- 程序流程，静态分析，动态分析找到时间状态关键，函数位置的RVA（relative virtual address），VMI插入trap当函数执行时候，安全记录，退出出的时候记录。local PCR
- 内存数据（磁盘数据由抗回滚数据域解决），静态，动态分析找到，安全关键数据（时间相关函数的关联数据），位置
- 随机数设备 -> 监控 /dev/random, 或者是 tpm自身的设备
快照、回滚发生后的应对策略
没有回滚过的状态我们认为是时间上安全的状态，主要是帮助过去的虚拟机维持没有回滚过的状态。
事件推送，关联方的感知机制
- 首先回滚必须能够及时可信的记录，并且推送到各个remote PCR，进行回滚感知，进一步的信息通过远程证明可以获得。
- 感知交互方发生回滚之后，针对抗回滚监控域的状态。
- 如果虚拟机存在快照，保存当前状态下的安全监控域的状态。
- 将调整（触发试监控的跳过需要完全的快照，如果单单是持续监控只需要对监控日志进行划分）抗回滚监控域的安全监控状态，监控产物数据的安全保护与验证。针对具体的监控软件，还需要恢复使用的句柄，xc 句柄，libvmi的句柄数据。
- 当交互服务方方感知到回滚，交互进程，数据进行释放，清空（如果一方发生回滚，可靠通信出现过期的序列号）
- 一般的交互服务在对方回滚之后自身的连接将会断开
- 为什么呢？针对交互过程中的数据进行销毁，其他完成以完成的事务的状态进行保存
其次需要对丢失状态进行验算
- 收集local 以及 remote PCR measurement Chain，与交互日志。
- 构造回复操作序列，什么样的序列能够使得重放后到达安全一致的虚拟域状态。
- 已经完成的操作（写入磁盘的操作，不需要进行恢复）
- 未完成的操作，比如说？
状态恢复， 以及新状态的达成
- 状态恢复之后的状态和回滚时的状态并不是完全一样的，当前的状态验证链是一个新的值，同时日志的内容也会发生变化。
时间安排
系统设计实现：
- 3月21日
- 3月28日
- 4月4日
- 4月11日
- 4月18日
- 4月25日
- 5月2日
- 5月9日
- 5月16日
论文撰写
- 4月18日开始撰写设计部分，威胁模型
- 5月1日，安全分析，国内外研究现状，介绍，总结
- 5月10日，撰写系统实现，以及性能测试
