on-the-fly-compartment

https://docs.google.com/presentation/d/1fVZlfJtHDvP3GEj31bMvFD9OVvtb9nGEMj6EDqXMRcI/edit#slide=id.p

new insight

1. point out and solve the object life timesystem during the on-the-fly comparmentalization.
2. fully understand what happened of a object's lifetime, when compartmentalization loaded by object not freed.
3. 为什么要在free的时候做数据对象的预测，在dereference的时候不行吗？（目前的想法是free的时候数据最全，可以促进ai预测，但是如果dereference的时候呢，有什么影响？如果第一次预测就能预测出来，后面不就不用预测了？）

task

• object数据对象生命周期，分配次数等等（eBPF直接干）
• object在不同阶段数据的变化
  • 证明object在生命周期的全过程是不停变化的，静态分析看看write情况（某个struct 有多少write指令）
    • 静态分析结果应该包括，哪些函数修改了struct，修改了struct的哪些member
  • 动态分析具体看一下数据的变化和对ml的影响
    • 分配时记录地址，然后在数据对象被修改的函数结尾处dump记录地址的内存，查看修改情况，最后丢给ML看看预测结果

---

2024 eurosys rejected, reason:1.story telling not focus on phase 0, 2.ptr deference(attack) to free, has a time window for attacker. 3.Bad reviewers.

Insight:

on-the-fly kernel compartmentalization can quickly remediate the 0-day hotspots (i.e. 0-day Vulnerability Highly Exposed Areas), 2 research questions are solved,

1. what happened in the past, before the compartmentalization, nothing is recorded for the runtime check, we design a ML-heuristic audition to solve it.
2. what for runtime check, cannot accurately decide the legal access range of an instruction, we use an conservative legal access set

it can work on the fly, and no need special hardware features as other solution did.

Introduction

On-the-fly security has become an essential requirement in the realm of hotpatching and vulnerability prevention, as it allows for the swift rectification of n-day security issues while maintaining service functionality. As security threats escalate in severity, it is imperative that countermeasures against 0-day threats also adopt an on-the-fly approach.

On-the-fly kernel compartmentalization serves as a potent tool to promptly address vulnerabilities in 0-day hotspots (i.e., areas highly exposed to 0-day vulnerabilities), ensuring the system continues to operate correctly. However, this approach presents three significant challenges that need to be addressed:

• Integrating the compartmentalization framework during runtime.
• Determining the parameters for runtime checks. Typically, the framework scrutinizes the target addresses or object types of memory access instructions. However, runtime binaries often lack the necessary type information to accurately determine the legal access range of an instruction, while previous solutions have relied on hardware features or compile-time instrumentation.
• Understanding the context before the compartmentalization, as no records pertaining to kernel objects are available for runtime checks.

To address these challenges, we propose the following solution:

• Utilization of eBPF, an in-kernel virtual machine, to establish a Software Fault Isolation (SFI) framework. Because eBPF allows for efficient and safe code insertion into the kernel.
• Adoption of a conservative access range for runtime checks parameters, encompassing potential types and ranges of functions or compartments.
• Implementation of two distinct compartment policies for both the initialization and working phases:
  • During the initialization phase, the compartmentalization is newly implemented. The lifecycle of the original data is still ongoing. We use a machine learning heuristic method. This method deduces the type of original data from its content in the kernel memory. It helps in making informed decisions about memory access.
  • As the lifecycle of the original data ends, the framework logs all allocated memory details. The compartment then moves to the working phase. In this phase, the machine learning heuristic method is not needed. Memory access evaluations are done directly using the recorded data.

It's important to note that an object's lifecycle is generally short-lived (> 96% shorter than 1s), meaning the initialization phase will not last long.

ML heuristic method:

• data set collection: in ebpf-project, a eBPF program to dump allocation site and content
• ML alogrithms and Model training: ?

毫无疑问，object在kfree时内容是最全面的，但是大概率和函数使用中的内容是不同的，既然已经打算做log&audition，不如在函数指令访问的时候只记录一个log，在object释放的时候，因为已经知道了具体的类型再进行audition （解决了不同阶段采样数据不同的问题）

• how to get all accessed buddy memory in the function? static analysis seems cannot do that

performance overhead.

In this section, we are aiming to evaluate the performance overhead of \sys. We have designed a series experiments to answer the following research questions,

1. what is the performance overhead to the system when isolating untrusted kernel modules into compartments, do quality of functions in the compartment effect?
2. what is the performance overhead to the compartment module, do the quality of functions in the compartment effect? How does it compare to related work?
3. how long should the phase 0 machine learning audition lasted?

experiment setup

Frist of all, we choose 3 modules for evaluating \sys, They come from the net subsystem, the most vulnerable subsystem in the kernel, accounting for more than 20% of all vulnerabilities more than 100 recent 3 year vulnerabilities have been found in these modules, they are ipv6 modules for parsing IP protocal version 6 in the linux net stack, netfilter modules for filtering network packets and performing network address translation (NAT), and sched for network packet scheduling and traffic control (QoS, Quality of Service).

For the first research question, we want to find the performance overhead to the system caused by \sys, so we design experiments by running kernel benchmarks alongside with different compartments, and compare the overhead with vanilla/stock kernel For benchmark programs, we choose the classic LMBench to evaluate the kernel core operations. We also choose phoronix test suites to evaluate the real world applications, include, perf, apache/nginx-ipv4, git, sqlite, redis, xz compression, and kernel compilation. For the compartments, We've chosen three modules, and for each of them we've built two separate compartments, one that isolates just one of the module's vulnerable files, and one that isolates the entire module. the vulnerable files are ip6_output.c in ipv6, nf_tables_api.c in netfilter, cls_route.c in sched, they include, x, y, z eBPF hooks. and the module ipv6, netfilter, sched, their compartment include x1, y1, z1 eBPF hooks. We also want to know the scalability, when install 3 compartments in the system at the same time. Besides, Because in phase 0, there is addtional ML audition in \sys compartmentalizaiton, so we test each compartment and 3 compartments together, when are using ML audition and not using ML audition.

For the second research question, we want to find the performance overhead to the comparted modules, so we design experiments by testing the its main ser ice's performance loss. So we choose apache Bench to test the ipv6 compartment's performance loss on request per second and transfer rate. The experiment setup is identical with the related work HAKC, by access 3 files, 100kb, 1mb, and 10mb for 1000 times through a ipv6 address. we setup a ipv6 local webserver with \Code{python -m http.server --bind [::1]:8000},because our IST doesn't support ipv6 services to the world wide web. and similar to the first experiment, we test apache bench 2 compartments, compartment a vulnerable file and the entire module, and under 2 situations, using the ML audition and not using it.

experiment result