sec19-ERIM: Secure, Efficient In-process Isolation with Protection Keys (MPK) Insight面对在共享内存中隔离进程关键数据的需求，ERIM提供了一个利用Intel MPK机制来近乎零开销的隔离组件的机制。使用MPK比现有SoTA开销低3-13倍，但是MPK本身不安全，因为写PKRU寄存器是无权限控制的。ERIM提供了一个保护安全性的机制。Background这里要介绍一下MPK，MPK提供了16个保护键，每个页面都可以与其中一个关联。提供了一个每个核心独立的寄存器PKRU，PKRU决定了当前核心在每个域的访问权限。并且这种权限检查是无开销的。PKRU使用用户态命令WROKRU和XRSTOR两条指令，但是这两条指令本身并没有被很好的保护起来，ERIM提出的机制正是为了保护指令避免被恶意攻击使用。DesignERIM的前提是系统的一些基础保护，如NX、DEP等保护已经开启，并且可以访问核心区的代码必须是完全可信的。design principleERIM通过限定WRPKRU和XRSTOR的出现条件实现对指令的保护，其要求相关指令在执行后必须进入预定几个几个流程之一对于WRPKRU，要么进入预定的入口点，这样即使权限错误，也只会进入到可信的代码后续操作未访问隔离内存，并且会结束进程对于XRSTOR后续指令必须是一段检查eax寄存器的代码，因为如果eax没有被控制，PKRU不会被错误的设定call gateERIM为可信代码设计了预定的入口点，在入口点调整PKRU，并将控制流转交可信代码，在可信代码完成之后，再调整PKRU。调用门有所限制。binary inspection二进制扫描包含WRPKRU字节序列的页面是否安全，这需要提前获得指定的入口点列表。通过二进制扫描来确保是否符合给定条件。

OSDI14- Arrakis: The Operating System is the Control Plane Wordsmediate v. 调节，斡旋negligible adj. 微不足道的Insight传统服务器通过内核协调进程隔离和网络、磁盘等IO设备的安全性，本文实现了一个操作系统，允许应用程序IO跳过内核。也就是所谓的控制平面和数据平面分离。Achievement一个典型NoSQL场景下的存储延迟优化了2-5倍，吞吐量提高了9倍提出了一种分工架构，并实现了一个原型操作系统，在此基础上测量了一部分现实服务的性能Breakdown Analysis从网络开始，传统Linux接受一个网络包的时间在微秒级别，通常是3us、6us两个时间级别，差别在于收包进程是否在idle，并且相差的开销以schedule带来的开销为主。而在3us中，主要的时间都浪费在了网络栈上。主要的开销集中于以下四点网络栈开销调度器开销内核切换开销数据包复制开销除此之外，多核导致的缓存和锁也会增加开销Arrakis可以完全消除调度器和内核切换的开销，并且极大的消除了网络栈和数据包复制的影响。同时文章分析了在存储侧系统调用带来的影响，以1KB为例，ext4的CPU开销大概要在30us级别，btrfs在70us级别，而RAID缓存的写延迟大概25us，闪存低至15us，这意味着文件系统带来的开销甚至要比硬件写入的开销更大。后续的阅读中我可能没再关注网络侧的内容，主要关注Storage，以及他们提出的这种硬件模型所提供的能力及用途。Design&Imp文章描述了一个基于一类特定的（主要是硬件级别支持虚拟化的）IO设备的架构。现有设备和控制器只能在某些方面实现他们提出的这种硬件模型。访问层级主要分为App、LibOS、VSIC、VSA和Device。App通过定制的UserSpace Lib来访问VSIC，即虚拟存储界面控制器，同时，硬件设备需要将物理段映射为多个虚拟存储区域VSA，VSA和VSIC是一个多对多的映射关系，VSIC由App创建。App通过API可以通过VSIC中的命令队列读取、写入VSA中任意偏移和大小的磁盘，完成使用doorbell通知。整个用户访问文件的流程不需要操作系统介入。那么问题就到了文件是如何共享和访问控制的。Arrakis分离了文件的命名和实现。App可以任意的通过VSA存储metadata和文件等内容。并可以将文件、目录名导出到vfs中，仍由原App管理，外部的访问不会被内核干预。外部访问可以通过RPC把原APP当做一个Server访问，或者源程序提供一个可以独立运行的进程。VSA也可以映射到多个进程中，此时访问APP需要能读到原APP的metadata，并能有适当的库解析文件内容。访问控制控制整个VSA是否可见。用户可以直接导出文件为标准格式。我感觉这三个方案都有点过于牵强了。

FreeBSD Arch Handbook阅读笔记 #7 VM https://docs.freebsd.org/en/books/arch-handbook/vm/7.1 vm_page_tvm_page_t 管理物理内存，每个vm_page_t对应一个物理页面，vm_page_t属于不同双向链表队列。主要包括活动、非活动、缓存或空闲。缓存和空闲的分页队列更加复杂，会根据L1和L2 Cache的大小分成多个队列。申请新页面的时候也会从Cache的角度来申请对齐的页面。页面通过引用计数持有，通过繁忙计数锁定。VM system通过LRU来对页面进行降级。对于Weird类型的页面，不在队列里，通常是载有一个页表。空闲链表里的页面是真正空闲的，而Cache链表里的页面随时可被重用。当进程访问一个不在页表里的页面时，如果页面在页面队列里，页错误就会导致更少的开销。否则只能从外存读入了。pageout守护进程负责：动态调整分页队列、维持各个队列页面合理比例维持脏页面和干净页面的细分（清洗脏页、升降级）VM会尝试在产生合理的页错误量级的前提下帮助决策何时换出和清洗页面。7.2 vm_object_tFreeBSD实现了一个通用内存对象，这个对象的backend可以是：TypesunbackedSwap-backedPhysical device backedFile-backedVM对象可以被遮蔽，具体可以看我的另一篇笔记https://yirannn.com/source_code/vm_sys.html比较常见的应用就是cow一个vm_page_t同时只能和一个vm_object关联。而不同实例的内存共享由遮蔽特性提供7.3 struct buf对于vnode作为back的vm对象，比如file，对脏页信息的维护和vm对脏页信息的维护是相互独立的。在写回脏页时，vm需要在写回前清除dirty标记。另外文件也需要将文件映射到KVM才能进行操作，这种结构被称为文件系统缓冲区，一般是struct buf，文件系统需要对VM进行操作时，把这个vm对象转换为一个buf，然后把buf中的页面映射在KVM里。同理，磁盘IO也是先把vm_object映射到buf，再在buf上发出IO。7.4 vm_map_t, vm_entry_tFreeBSD通过vm_map_t结构把object和虚拟内存范围相关联，页表通过vm_map_t/vm_entry_t/vm_object_t 直接合成。这一段我其实没太读懂，但是我感觉笔者意思是一个物理页不光是和一个vm_object联系，同时也和页表项联系。但是对于同个object的同个页面，对应的vm_page_t都相同7.5 KVM 内存映射FreeBSD用KVM保存内核结构，其中最大的就是7.3中提到的buf。FreeBSD不会把所有物理内存都映射到KVM，主要利用区域分配器管理KVM