Arachne【源码分析】及AESA、PortSmashA

相关内容可以参考论文《Partial-SMT: Core-scheduling Protection Against SMT Contention-based Attacks》

Arachne模块划分

CoreAbiterServer：处理句柄、建立断开连接、核请求和释放、阻塞线程、核调度（核心函数，功能是先给被抢占的线程分配核再给被阻塞的分配核，distributeCore）。

这些核调度的规则如何落实到线程？应该是通过socket的阻塞（sys->read）。如何具体将不同线程放到指定核心上？通过交换CoreID对应的上下文（swapcontext）。

CoreAbiterClient：通过Socket和共享内存与Server交互，发出请求，具体功能由Server完成

Arachne：向用户提供API，会调用CoreAbiterClient等。

Arachne代码流程图

https://github.com/PlatformLab/arachne-all

Init函数（主线程）

首先分析命令行参数来设置全局变量等（parseOptions）。配置好CoreArbiterClient（其中Socket位置：/tmp/CoreArbiter/socket）。根据命令行参数中的核数量分配做一个默认的CorePolicy。

发送核数量请求（CoreArbiterClient::setRequestedCores），具体会通过CoreArbiterClient来向CoreArbiterServer发送请求。

这需要CoreArbiterServer先启动起来，并与之建立连接。告诉CoreArbiterServer我的进程ID、线程ID。如果当前线程的对应进程刚创建，则之后会收到全局内存共享、进程内存共享的地址，然后地址对应的文件映射到内存（分别取名为globalStats、processStats）。

通过建立好的连接，发出各个优先级的核数量请求（CORE_REQUEST）。

根据可供管理的核数量，建立若干内核线程（入口是threadMain）。

初始化主线程的核信息、栈信息及其他信息。

CreateThread函数（主线程）

某些信息的维护，关键的是把目标Main作为一个task保存到数据结构中，用于之后调度。

threadMain函数（内核线程）

初始化核心信息。阻塞自己直到获得核ID（CoreArbiterClient::blockUntilCoreAvailable）：发送THREAD_BLOCK到Server。等待核分配。

分配到核之后，信息维护，包括初始化栈，返回地址指向schedulerMainLoop，之后会通过swapcontext转换到schedulerMainLoop。

信息维护，dispatch等待任务（目标Main）到来（不断的遍历context，直到有一个context包含任务，没有时间片的概念，任务执行完去执行下一个），然后运行它。

CoreArbiterServer（需root权限）

配置CPUSet的相关信息。包括受管理的核和不受管理的核。

【细节】

$cpusetPath=/sys/fs/cgroup/cpuset

$arbiterCpusetPath=/sys/fs/cgroup/cpuset/CoreArbiter

$managedXCpusetPath=$arbiterCpusetPath/ManagedX

$unmanagedCpusetPath=$arbiterCpusetPath/Unmanaged

默认将除核0外其他核都作为Managed Core，并创建目录（$arbiterCpusetPath/ManagedX|Unmanaged)。先设置Unmanaged CPUSet：将当前进程放到Unmanaged CPUSet下（$cpusetPath/cgroup.procs的进程转移到$unmanagedCpusetPath/cgroup.procs），创建管理Unmanaged CPUSet中核心数量、线程的文件（$unmanagedCpusetPath/cpuset.cpus|tasks）。然后设置Managed CPUSet：创建$managedXCpusetPath/tasks

【细节结束】

（将某个线程绑定到特定核，应该是通过cpuset来实现的）

配置全局共享内存（/tmp/CoreArbiter/sharedmemoryGlobal，修改权限让Client端无需root权限），设置listenSocket和epoll用于监听请求。

真正地启动CoreArbiterServer，进入一个循环等待并处理请求的函数（handleEvents，具体由epoll_wait不断等待请求）。

建立连接：当Arachne线程通过CoreArbiterClient发出连接请求时，listenSocket（只有本端的地址，没有对端的地址，只能通过epoll来触发）接收到，并建立一个Arachene线程专用的Socket（有两端的地址信息），从Socket收到Arachene线程的进程ID、线程ID。如果对方的所属进程第一次与我建立连接，那么我就配置进程共享内存（/tmp/CoreArbiter/sharedmemory$processId），将全局共享内存和进程共享内存通过socket发给Arachne线程。

收到各个优先级核数量的请求（CORE_REQUEST）。进行信息维护，如请求与上一次请求有变，则进行核调度（distributeCores）。

收到阻塞线程的请求（THREAD_BLOCK）。根据情况阻塞线程（已运行在托管核上的内核线程如果被Server要求回收核，那就回收内核，不然让内核线程继续运行，即不阻塞）。之后进行核调度，（把），直到有可用的核给内核线程。

当托管核变为非托管核，会出现核上线程存在的情况。抢非托管核会出现抢占情况。

AesA性能分析

https://github.com/LihengChen9/AesA

(AESA是使用Arachne线程库对AES进行多线程运算。AES代码取自openssl。AESA跑的数据可以看Github仓库)

当线程执行时间<几十ms时，我们可以看的pthread和arachne线程周期基本相同，说明两者线程执行时间基本相同，我们调大线程任务量一个量级，可以发现pthread线程随着线程数增多，单线程任务量减少，线程周期并没有减少，而arachne的仍然会减少，这主要是因为pthread存在执行一个时间片会挂起的原因，导致线程周期大于线程真正执行时间，因此体现出来的时延也高了。

Arachne总时长略高的原因是，arachne线程的负载均衡程度会略差一些。可以看到，随着线程数量增加，arachne总时长会趋向ps模式，因为线程数量多了，每个线程任务量少了，负载均衡略差的影响变小了。

Arachne在多线程，单线程任务量少的时候，单线程周期相比pthread模式短，但是总时长和ps模式差不多。总时长不如pd模式，是因为pd模式真正的多个物理核，因为AES场景下，每个线程都是实实在在的工作，没有闲下来的时候，所以比如2个逻辑核不如2个物理核来的实在。关于开关SMT下的对比，使用相同数量的物理核，性能没有提升，应该也是因为Aes场景的原因，分出来逻辑核没有出现性能优势。（Intel给的数据有点不同，他在Aes下开SMT有性能优势，我怀疑是因为它实验的cpu一个物理核中有很足够的功能部件，使得两个逻辑核之间不会出现资源抢占，好比它的cpu一个物理核有两条马路，我的cpu大部分时候两条马路，中间有一段两条马路合并了）。

PortSmashA及相关科普

https://github.com/bbbrumley/portsmash

https://github.com/LihengChen9/PortSmashA

（PortSmashA是利用Arachne防御PortSmash）

System() popen()函数都是先通过fork出一个子进程来执行命令，会调用exec族函数具体执行命令，system会等待子进程完成后再返回，而popen利用管道，使得子进程依然执行，并且popen函数返回。】

其中exec族函数会将当前进程替换成命令指定的线程（pid不变，但是上下文都变了），通过人工检查pid，发现尽管是进程的子线程调用exec族函数，整个进程的上下文依然全变了。（所以直接victim进程创建Arachne线程运行exec族函数后，所谓的新Arachne线程没有了，所谓的内核线程没有了，变成了会被挤到非托管核的全新的进程，不再和Arachne有任何相关，也没法再安排一个dummy的Arachne线程来占据Sibling Core，所以不推荐）

Taskset -c在CoreArbiter下，会出现”taskset: 设置 pid XXXX的亲和力失败: 无效的参数”，但并不代表spy就失败了。将ecc的Arachne线程放到核7，spy的Arachne线程放到核3，仍然会出现冲突，但是由于ecc的Arachne线程对应的内核线程会空转，使得ecc不执行时，ecc对应的内核线程也可能存在add等操作，使得spy探测的延迟为全程高延迟。

*为了实现真正的安全（上述仍然可能造成攻击），我们可以在ecc这个受害者这端，开一个dummy的Arachne线程，来完全占据Sibling Core（同进程的Arachne线程优先占据同一个物理核，CoreArbiterServer的调度算法这么写的），这样spy就没法和ecc到同一个物理核。

此外，还发现尽管sched_getcpu和getaffinity会有一致性的维护，但是非Arachne线程的/sys/fs/cgroup/cpuset与上述两个函数（数据结构）存在不一致性，Arachne线程存在一致性。可能是因为非Arachne线程是强行被放到非托管核上，但是并没有通知sched_getcpu和getaffinity两个数据结构。