新机制，新考验 - Windows10(14316) Linux子系统分析

〇.背景
在build 2016大会上，微软宣布windows10 中将原生支持bash，并且号称在windows中加入了一个Linux子系统（Windows Subsystem for Linux），而不是一个虚拟机。而后在发布的win10 14316(x64)更新上就开启了bash功能，但32位版本没有bash。
笔者随即下载了14316想体验一下windows上执行bash命令，并且想了解这个Linux子系统机制的实现。

一.介绍
首先打开system32\bash.exe后，随便输入一个ls命令，通过procmon发现有进程访问了C:\Users\xxxxx\AppData\Local\lxss\rootfs\bin\ls文件。

随即发现了linux根目录挂载在C:\Users\xxxxx\AppData\Local\lxss\rootfs,可以看到目录结构和ubuntu基本一致。

反过来看到访问ls这个elf文件的进程比较奇怪，procmon无法显示进程名字，而且挂上调试器还会发现这个进程对象内不仅没有名字，也没有section，peb等信息。
二.Pico Process
这种没有名字的进程称为pico process，也就是ELF的宿主进程。关于picoprocess介绍: http://research.microsoft.com/en-us/projects/drawbridge/#Picoprocess。简单来说Pico Process是一种Container，实现drawbridge沙盒技术的一种机制，并且之前被微软毙掉的“Project Astoria”项目也用到了lxcore+picoprocess这种技术。现在微软把这种技术应用到了win10 linux子系统当中。

Picoprocess统一由PspCreatePicoProcess创建，而PspCreatePicoProcess里面主要的工作是由PsCreateMinimalProcess实现的，PsCreateMinimalProcess这个函数的名字像是用于创建一个精简进程，实际上确实也是这样。PsCreateMinimalProcess里面会调用PspAllocateProcess，PspAllocateProcess函数本身的功能是用来创建EPROCESS对象，进程地址空间，PEB等信息。
PspAllocateProcess函数的原型大致如下：
NTSTATUS
PspAllocateProcess(
void *ParentProcess,
int PreviousMode,
void *ObjectAttributes,
char Protection,
char SignatureLevel,
char SectionSignatureLevel,
void *SectionObject,
void *TokenObject,
int Flags,
void *UserProcessParameters,
int bSystemToken,
OUT int a12,
OUT void *Process)
而PsCreateMinimalProcess中调用PspAllocateProcess的参数如下图所示，可以发现ObjectAttributes，SectionObject，等都为NULL，这也论证了之前我们看到picoprocess没有进程名，没有用户空间信息等现象。

再回来看PspCreatePicoProcess这个函数的调用栈，可以看到ring3的调用是由PsPicoSystemCallDispatch这个函数分发到lxcore驱动中的，这里需要引出另一个东西：PicoProvider

三.PicoProvider
Nt导出了一个函数PsRegisterPicoProvider提供注册一个PicoProvider，在目前只有lxss.sys会调用这个接口，lxss.sys和lxcore.sys这两个驱动负责实现linux子系统的大部分功能。Lxss.sys作为一个boot start driver会在初始化时调用lxcore.sys->PsRegisterPicoProvider，而且PsRegisterPicoProvider在系统启动后只允许调用一次，在所有boot driver初始化完毕后，nt会把PspPicoRegistrationDisabled设置为TRUE，从而禁止以后所有的PsRegisterPicoProvider调用，也就是说当前系统只允许存在一个Provider。

注意因为目前最新的符号只是14295，14316的符号微软还没有放出，但lxss.sys相关的文件在14295就存在了并且大部分功能nt中已经使用了,只是上层机制并没有实现。所以笔者使用14295的符号配合14316文件来分析lxss内核相关机制，如有不正确欢迎指出。
PsRegisterPicoProvider的原型大致如下：
NTSTATUS PsRegisterPicoProvider(
IN PICO_INTERFACE *PicoInterface,
OUT PSP_INTERFACE *PspInterface
);

struct PICO_INTERFACE
{
__int64 cbSize; //目前只支持0x48，不排除以后会有EX
PVOID PicoSystemCallDispatch;
PVOID PicoThreadExit;
PVOID PicoProcessExit;
PVOID PicoDispatchException;
PVOID PicoProcessTerminate;
PVOID PicoWalkUserStack;
PVOID LxpProtectedRanges;
PVOID PicoGetAllocatedProcessImageName;
}
struct PSP_INTERFACE
{
__int64 cbSize; //目前只支持0x60
PVOID PspCreatePicoProcess;
PVOID PspCreatePicoThread;
PVOID PspGetPicoProcessContext;
PVOID PspGetPicoThreadContext;
PVOID PspGetContextThreadInternal;
PVOID PspSetContextThreadInternal;
PVOID PspTerminateThreadByPointer;
PVOID PsResumeThread;
PVOID PspSetPicoThreadDescriptorBase;
PVOID PsSuspendThread;
PVOID PspTerminatePicoProcess;
}
Lxss通过PsRegisterPicoProvider向NT提供一组PICO操作接口，以获取系统调用分发、进线程退出、异常访问等消息、自己进行处理。并且会获取NT的一组进线程操作接口，用于对nt进线程进行操作。其中有一个PICO接口PicoGetAllocatedProcessImageName，比较感兴趣，因为之前提到了我们用procmon观察pico process是没有名字的，并且内核调试器也无法看到名字，如果能知道pico process对应哪个ELF会对分析有很大帮助。
通过分析，Pico Provider把这个接口提供给NT，在NtQuerySystemInformation获取进程名相关信息的时候，正常情况下会从EPROCESS->SeAuditProcessCreationInfo中取进程名信息，但如果发现这是个pico process则调用PicoGetAllocatedProcessImageName获取。所以逻辑上说NT已经做了对pico process的兼容，但为什么procmon还是无法获取进程名？果然笔者自己试了下用最简单的CreateToolhelp32Snapshot是可以轻松枚举到elf进程相关的名字。
所以procmon可能并不是用标准接口来获取进程名字的。

但pico process的进程名保存在哪里呢？通过分析这个函数，发现pico process对应的ELF路径信息保存在EPROCESS->PicoContext +0x15b0处，而PicoContext是在创建pico process的时候，由PspCreatePicoProcess设置的,保存了pico process的各种信息。用一个简单的脚本，用来遍历当前系统的pico process的名字信息，这是当我使用bash执行一个wget下载任务的时候的pico进程信息：

继续说回PsRegisterPicoProvider，PICO Interface中的PicoSystemCallDispatch也比较重要。负责分发pico process传来的系统调用，用于picoprocess和provider进行通信。在pico process的一次系统调用中，当ring3代码sysenter后，内核入口为KiSystemCall64，如果当前thread->_DISPATCHER_HEADER中设置了Minimal标志位，则KiSystemCall64会调用nt!PsPicoSystemCallDispatch进行pico相关分发，不走原始的sdt分发表。Lxcore!LxpSyscalls保存这个分发表的地址。
这是打印的部分分发函数，类似SDT表一样，仍然是通过rax作为id分发，但参数的传递和走sdt的有一些不一样。使用rdi,rsi,rdx,r10传递参数。
(分析过程中还发现14316后多了一张新的SDT表KeServiceDescriptorTableFilter，当一个线程flag被设置为RestrictedGuiThread时，则使用KeServiceDescriptorTableFilter这张表，这张表会限制很多native api的调用，主要限制edge等进程调用win32k等函数，做更严格的安全性隔离，不过目前KeServiceDescriptorTableFilter的内容还是和普通的SDT一样，应该还未使用)

我们来看下lxcore提供给Linxu子系统一些功能的实现。比如当我们使用bash创建一个ELF进程的时候，lxcore的调用流程大概是：LxpSyscall_FORK->LxpThreadGroupFork ->LxpThreadGroupCreate –>PspCreatePicoProcess。PspCreatePicoProcess在之前PsRegisterPicoProvider的时候已经从NT中获取了，所以lxsscore可以操作nt的进线程，但对于没有向NT获取响应的接口的其他功能呢？
对于文件系统的操作则直接调用相应的nt api，而并非直接和文件系统打交道，比如当使用rm命令删除一个文件的时候，调用流程：LxpSyscall_UNLINK->LxpUnlinkHelper->VfsPerformUnlink->VfsUnlinkChild->LxDrvFsRemoveChild->LxDrvFsDeleteFile->ZwSetInformationFile，其中会通过LxDrvFsDeleteFile 会使用IoCreateFile打开文件，再进行删除。 lxcore.sys中实现了一套VfsXXXX接口向上虚拟了VFS，向下使用LxDrvFsXXXX的一组API提供文件访问能力。
对于网络的操作，分为UNIX协议簇和INET协议簇，两个有不同的分发表，比如当上层发送一个UDP包的时候，lxcore的调用流程: LxpSyscall_SENDMMSG->LxpSocketSendMultipleMessages->LxpSocketInetSendMessage->LxpSocketInetSend->LxpSocketInetDatagramSend->afd!WskProAPISendTo。最终会进入到afd执行相应的功能。这是打印出来的lxcore使用的Afd相关函数：

再其它的一些，比如获取当前系统信息，lxcore也是直接调用Nt相应的函数获取，例如date命令，lxcore通过LxpSyscall_CLOCK_GETTIME->KeQuerySystemTimePrecise获取。
四.注入Pico Process
最后试了一下注入到pico process，打算注入进去调用一下pico process的分发表，由于pico process没有section对象所以无法用远程线程注入。最后使用SetThreadContext方法注入到了pico process进程。虽然可以注入成功，但windbg是无法调试pic process的，因为lxcore接管了pico process的异常分发，nt!KiDispatchException中如果发现异常在pico thread中，则使用PicoDispatchException处理异常，lxcore中使用APC模拟signal机制处理进程通信与异常分发。
五.总结
目前来说LxpSyscalls目前包含0×138个调用，而且有些调用目前内部没有逻辑实现，所以微软在未来会逐渐完善各种命令的支持。上面简单分析了一下lxcore对于linux子系统操作的支持，当然只是部分操作，还有一些比如ELF加载，内存管理，设备管理等都还没有分析。但从目前已经分析的结果来看，微软确实是自己实现一套linux子系统支持，并不是一个Linux虚拟机，所以执行效率会好很多，比如pico process的进程的时间片分配和原生的process基本一致。但是缺点也是有，增加了一套lxss机制后，同时也增加了复杂性，也就是说win10以后可能会面临win和linux二进制安全的双重考验，这可能对windows的安全性保障又增加了新的难题。