Practical Protection of Kernel Integrity for Commodity OS from Untrusted Extensions

发表于 更新于 分类于
论文的部分翻译与总结

challenge

  • 针对于单一方面的攻击和防御能够非常有效，比如针对于code完整性，数据完整性和控制流完整性。但是没有针对于多方面的共同保护。

  • 如何使得保护变得通用和实用。比如一些有问题的driver中，某些函数可能是良性的，有些函数是恶意的。很多方法虽然保证了控制流完整性，但是同时也禁止了良性函数的运行。需要达到更细粒度的保护。

  • 现有可以用VMM在OSkernel上再加一层的保护，这种方法虽然有效，但是只能保护很小一部分的object，并且会有很大的开销问题。

target

  • kernel code/data不能被不可信的extenstion修改
  • 寄存器（控制寄存器，标志位寄存器）等硬件结构环境不能被不可信的extenstion修改
  • 控制流不能被不可信的extenstion修改，函数调用一致性（call-return consistency）必须被严格遵守
  • 栈完整性保证，恶意代码不能被注入kernel栈；不可信扩展不能通过自己栈上的番薯指针和返回地址推翻控制流；在栈上属于kernel的non-control data不能被不可信扩展腐败。

HUKO

  • 提供了四种状态，user,oskernel,untrusted extensions,trusted extensions.
  • 针对于不同的状态用不用的HAP（硬件辅助页表，即EPT等）来标识不同权限，针对TLB做优化
  • 对于kernel的不同object（task_struct等关键数据）做了label（具体来说应该是给含有object的物理页打了标签），这些标签用了页表中reserve的bit，最多支持32种类型的标签。
  • 并实现了一个trusted driver，用来关注hypervisor的分配和回收页面，并且关注guest对于页面的使用情况，讲情况报告给hypervisor。
  • 把所有kernel symbol table以及一些管理员认定的label成trust。所有新load的都是untrust。管理员可以认证其为trust。如果untrust做了一些违规操作就是报错。所有untrust的行为会被跟踪。

实现细节

  • 对于一些大页，可能混合了data和code，就把2M的page细分成512个4KB的page，对于4KBpage打混合标签，所有的访问都会引起hypervisor的关注。
  • 实现了一个labeling helper的extension，用以帮助trace 动态的object（静态的像kernel code 这些都在systemmap上知道地址），告知hypervisor分配页面的时候什么页面上的object是什么（用hypercall接口告知）。

一些奇怪的点

他claim自己低overhead，实际上是和shadow page table 和EPT比较，当然overhead低啊。