最近，苹果公司推出了自家研发的芯片M1 SoC，其中含有许多有趣且未公开的硬件新特性，例如SPRR机制可用于重新定义页表权限位的含义，而GXF机制则引入了横向执行级别。在这篇文章中，我们将为读者详细介绍这些新特性，以及苹果公司是如何利用它们来保护macOS系统的。
（接上文）
通过Python探索未知的系统寄存器
实际上，m1n1最大的特点就是：允许直接通过python shell来操作硬件，而不是重新编译和重新加载shellcode，以及通过python来处理数据提取和所有这些恼人的琐事。marcan最近还合并了我的USB gadget代码，因此，大家要想复现这些实验的话，只要一台M1 Mac和一根普通的USB线就能搞定了。
让我们从运行proxyclient/shell.py开始。不幸的是，访问用户态的SPRR寄存器只是触发了一个异常。（但我注意到，m1n1很快从这个异常中恢复过来了，根本不需要重启！)
>>> u.mrs((3, 6, 15, 1, 5)) TTY> Exception: SYNC TTY> Exception taken from EL2h TTY> Running in EL2 TTY> MPIDR: 0x80000000 TTY> Registers: (@0x8046b3db0) TTY> x0-x3: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 TTY> x4-x7: 0000000810cb8000 0000000000007a69 0000000804630004 0000000804630000 TTY> x8-x11: 0000000000000000 00000000ffffffc8 00000008046b3eb0 000000000000002c TTY> x12-x15: 0000000000000003 0000000000000001 0000000000000000 00000008046b3b20 TTY> x16-x19: 00000008045caa80 0000000000000000 0000000000000000 000000080462b000 TTY> x20-x23: 00000008046b3f78 00000008046b3fa0 0000000000000002 00000008046b3f98 TTY> x24-x27: 00000008046b3f70 0000000000000000 0000000000000001 0000000000000001 TTY> x28-x30: 00000008046b3fa0 00000008046b3eb0 00000008045bad90 TTY> PC: 0x810cb8000 (rel: 0xc70c000) TTY> SP: 0x8046b3eb0 TTY> SPSR_EL1: 0x60000009 TTY> FAR_EL1: 0x0 TTY> ESR_EL1: 0x2000000 (unknown) TTY> L2C_ERR_STS: 0x11000ffc00000000 TTY> L2C_ERR_ADR: 0x0 TTY> L2C_ERR_INF: 0x0 TTY> SYS_APL_E_LSU_ERR_STS: 0x0 TTY> SYS_APL_E_FED_ERR_STS: 0x0 TTY> SYS_APL_E_MMU_ERR_STS: 0x0 TTY> Recovering from exception (ELR=0x810cb8004) Traceback (most recent call last): File "/opt/homebrew/Cellar/[email protected]/3.9.4/Frameworks/Python.framework/Versions/3.9/lib/python3.9/code.py", line 90, in runcode exec(code, self.locals) File " File "/Users/speter/asahi/git/m1n1/proxyclient/utils.py", line 80, in mrs raise ProxyError("Exception occurred") proxy.ProxyError: Exception occurred >>>
但是，内核必须能够在上下文切换期间修改这个寄存器。这就意味着可能存在一些使能位。幸运的是，m1n1存储库中已经提供了一个现成的python工具，可用于查找所有可用的系统寄存器。该工具的内部运作方式为：为所有寄存器生成相应的mrs指令，并从未定义寄存器引起的异常中恢复。下面，让我们运行它并寻找附近的寄存器：
$ python3 proxyclient/find_all_regs.py | grep s3_6_c15_c1_ s3_6_c15_c1_0 (3, 6, 15, 1, 0) = 0x0 s3_6_c15_c1_2 (3, 6, 15, 1, 2) = 0x0 s3_6_c15_c1_4 (3, 6, 15, 1, 4) = 0x0
这里给出了三个候选寄存器。如果将0x1写入第一个候选寄存器，似乎会导致m1n1无法正常工作——很明显，这说明m1n1是从具有rwx权限的页面运行的。SPRR寄存器最初的值为0x0，这意味着没有任何访问权限。如果SPRR突然启动，使CPU认为rwx实际上是---，会发生什么？一切都完了，因为没有可以读取或执行的内存了。
现在，让我们禁用MMU，并再次将0x1这些寄存器(并很快注意到第三个寄存器似乎只是引发了故障并忽略了该故障)，然后，查找所有寄存器，最后确定新的寄存器。这一切都可以通过几行python代码来完成：
with u.mmu_disabled():
for reg in [(3, 6, 15, 1, 0), (3, 6, 15, 1, 2)]:
old_regs = find_regs()
u.msr(reg, 1)
new_regs = find_regs()
diff_regs = new_regs - old_regs
print(reg)
for r in sorted(diff_regs):
print(" %s" % list(r))
u.msr((3, 6, 15, 1, 2), 0)
u.msr((3, 6, 15, 1, 0), 0)哦，天哪，有很多新的寄存器被启用了！
启用的系统寄存器
接下来，让我们把S3_6_C15_C1_0改名为SPRR_CONFIG_EL1。这里的第1位启用了SPRR，设置所有的位似乎可以锁定所有的SPRR寄存器，以作进一步的修改。S3_6_C15_1_2和它所启用的寄存器对于第二部分内容来说是非常重要的。
而我们现在确实可以翻转S3_6_C15_C1_5的所有位了：
>>> p.mmu_shutdown() TTY> MMU: shutting down... TTY> MMU: shutdown successful, clearing cache >>> u.msr((3, 6, 15, 1, 0), 1) >>> u.mrs((3, 6, 15, 1, 5)) 0x0 >>> u.msr((3, 6, 15, 1, 5), 0xffffffffffffffff) >>> u.mrs((3, 6, 15, 1, 5)) 0xffffffffffffffff >>>
虽然这个寄存器可能适用于EL0，但我们在这里的运行级别为EL2。我们可以做一个有根据的猜测，假设新启用的寄存器S3_6_C15_C1_6可能是用于EL1级别的，S3_6_C15_C1_7用于EL2。M1总是与HCR_EL2.E2H一起运行，它（除其他外）将对EL1寄存器的访问重定向到其EL2对应的寄存器。我们可以用下面的实验来验证我们的猜测：
>>> u.msr((3, 6, 15, 1, 6), 0xdead0000) >>> u.mrs((3, 6, 15, 1, 7)) 0xdead0000 >>>
到目前为止，看起来还很顺利：现在，我们可以启用SPRR机制了，而且发现了一个可疑的寄存器——它很可能与EL2权限有关。下面，我们将重复在用户态下面的实验了，以了解这些寄存器中上面介绍的四位以外的内容了。
逆向分析SPRR寄存器
我们可以编写一些python代码，来建立一个简单的页表，然后重复我们在用户态下面所做的那些实验。首先，映射一个页面，使其具备S3_6_C15_C1_6对应的权限，然后，尝试对其中的内存进行读/写/执行操作。
为了通过python代码完成上述操作，必须对m1n1本身进行一些侵入性的修改，使其从r-x内存页运行，并将其堆栈分配到具有rw-权限的内存页中。我们要力争通过Python完成尽可能多的设置工作，然后，编写一些shellcode并在其他CPU核上运行，这能够让事情容易得多：即使其中一个挂掉了，在重启之前，至少还有其他的可用。
pagetable = ARMPageTable(heap.memalign, heap.free)
pagetable.map(0x800000000, 0x800000000, 0xc00000000, 0) # normal memory, we run from here
pagetable.map(0xf800000000, 0x800000000, 0xc00000000, 1) # probe memory, we'll try to read/write/execute this
# ...
code_page = build_and_write_code(heap, """
// [...]
// prepare and enable MMU
ldr x0, =0x0400ff
msr MAIR_EL1, x0
ldr x0, =0x27510b510 // borrowed from m1n1's MMU code
msr TCR_EL1, x0
ldr x0, =0x{ttbr:x}
msr TTBR0_EL1, x0
mrs x0, SCTLR_EL1
orr x1, x0, #5
msr SCTLR_EL1, x1
isb
// [...]
""".format(ttbr=pagetable.l0)
# ...
ret = p.smp_call_sync(1, code_page, sprr_val)
# ...这样一来，过去的信号处理程序现在变成了一个小型的异常向量。我们在这里所做的只是修改一个寄存器来指示故障，然后在返回之前让程序计数器再跳过两条指令即可。第一条指令是发生故障的那条，我们不想再运行它了。第二条指令是mov x10, 0x80，表示访问成功，如果我们遇到了异常，访问肯定就不成功了。
_fault_handler: # store that we failed mov x10, 0xf1 mrs x12, ELR_GL2 # get the PC that faulted add x12, x12, 8 # skip two instructions msr ELR_GL2, x12 # store the updated PC isb # eret restores the state from before the exception was taken eret _sprr_test: # ... # test read access, x1 contains an address to a page for which we modify the SPRR register values mov x10, 0 # x10 is our success/failure indicator ldr x1, [x1] # this instruction will fault if we can't read from [x1] mov x10, 0x80 # this instruction will be skipped if the previous one faulted
通过上面的工作，我们最终得到了所有16种可能配置的含义：
很明显，这里有些地方很奇怪。在大多数情况下，较低的两个比特指定了权限。但有两个例外情况，较高的位也会以某种方式改变权限。0111似乎不允许访问一个本应是rw-权限的页面，而1001通常应该是可读和可执行的，但这里只有可执行权限。
按理说，根本就没有必要再浪费两个比特来编码这个权限。乍一看，这可能是用于处理用户与内核的write-or-execute权限。但我们知道，EL0使用的是一个完全不同的寄存器。那么，这还能是什么作用呢？
受保护的异常级别/GXF
从上一节我们知道，在PPR寄存器中编码了一些奇怪的东西。此外，之前我们也曾提到了受保护的异常级别，它与常规的异常级别是不同的。显然，这些是由0x00201420和0x00201400这两条被称为genter和gexit的定制指令触发的。
让我们把XNU附加到反汇编程序中，看看能否通过otool -xv /System/Library/Kernels/kernel.release.t8101找到一些可疑的东西。在查找这些指令时，发现了如下所示的可疑指令，它也恰好在初始化早期被调用：
fffffe00071f80f0 mov x0, #0x1 fffffe00071f80f4 msr S3_6_C15_C1_2, x0 fffffe00071f80f8 adrp x0, 2025 ; 0xfffffe00079e1000 fffffe00071f80fc add x0, x0, #0x9d8 fffffe00071f8100 msr S3_6_C15_C8_2, x0 fffffe00071f8104 adrp x0, 2025 ; 0xfffffe00079e1000 fffffe00071f8108 add x0, x0, #0x9dc fffffe00071f810c msr S3_6_C15_C8_1, x0 fffffe00071f8110 isb fffffe00071f8114 mov x0, #0x0 fffffe00071f8118 msr ELR_EL1, x0 fffffe00071f811c isb fffffe00071f8120 .long 0x00201420 fffffe00071f8124 ret
还记得S3_6_C15_C1_2吗？（我当时印象深刻，因为对我来说，所有这些数字看起来都一样。）这是我们前面找到的第二个使能寄存器，也是这里使用的第一个寄存器。然后，将两个指针写入未知系统寄存器，最后执行未定义的指令0x00201420。第一个指针只是指向一个无限循环，但第二个指针指向一个函数，它似乎也使用了我们前面找到的SPRR寄存器。
因此，S3_6_C15_C8_1中可能是一个指针，一旦0x00201420被执行，处理器就会跳转到这个指针。第二条未知指令0x00201420似乎在那时恢复执行。这一切听起来与管理程序调用的工作方式非常相似。0x00201420对应于smc，以捕获到EL3权限，0x00201400是eret，将我们带回EL2级别。不同的是，对于这种新的执行模式，没有找到不同的页表。还记得SPRR寄存器中未知的两个位吗？如果这些对应于GL2的页面权限呢？
我们可以通过使用与之前相同的方法，再次用m1n1快速验证这一点。我们在保护性执行模式下设置异常向量，并重复同样的实验。
但是，我们如何在这种新模式下设置异常向量呢？通常有一个叫VBAR的寄存器来实现这个目的。让我们简单看看S3_6_C15_C10_2所指向的代码，它是XNU在genter之后首先设置的寄存器之一。
fffffe00079e0000 b 0xfffffe00079e15d0 fffffe00079e0004 nop fffffe00079e0008 nop fffffe00079e000c nop [...] fffffe00079e007c nop fffffe00079e0080 b 0xfffffe00079e1000 fffffe00079e0084 nop [...] fffffe00079e00fc nop fffffe00079e0100 b 0xfffffe00079e11f0 fffffe00079e0104 nop [...]
唷，这看起来像是一个异常向量表，这意味着S3_6_C15_C10_2是VBAR_GL1。
这样的话，我们就得到了一个完整的权限表，并破解了SPRR寄存器的所有位的秘密。
这个完整的权限表看起来正是我们要找的：SPRR寄存器的值为0100、0110或1111时，如果从EL2跳转到代码时，内核似乎就会崩溃。所有这些值都对应于这样一个内存页：该页显然不能从EL2执行，但能从GL2执行。如果这些故障由于某种原因转移到不同的地址，结果会怎样？不要再拐弯抹角了，这正是现在所发生的情况。这三个特殊的故障使用了XNU指向无限循环的系统寄存器，即
· 当EL2试图跳转到只能在GL2中执行的代码时，引发的异常终止将转到S3_6_C15_C8_2（我称之为GXF_ABORT_EL2）；
· 任何其他来自EL2的异常终止都转到VBAR_EL2；
· 任何其他来自GL2的异常终止都转到VBAR_GL2。
这样的话，我们再次就得到了一个完整的权限表，从而破解了SPRR寄存器的所有位的秘密。
下面，让我们详细了解一下通过GL权限位修改EL权限位含义的两种特殊情况：
· 第一种情况（0111）确保无法创建在GL中可执行、在EL中可写入的内存页。这为防止软件漏洞提供了额外的硬件层保护。如果能够从EL中改变在GL中运行的代码的话，将使整个横向保护变得毫无意义。
· 第二种情况(1001)将r-x EL权限替换为--x权限，如果该内存页只能从GL中读取的话。我不知道为什么要强制执行这个保护。也许是为了能够对EL隐藏一些秘密代码，或者作为对我不熟悉的安全漏洞的一些额外缓解措施？我很想知道为什么这样的映射会有帮助，如果有人能够给出一个很好的解释的话。
利用Python探测GL2
掌握了这些知识，我们现在旧可以很轻松地在GL2和m1n1中添加对运行自定义payload的支持了。我们所要做的，就是利用已经存在的框架将运行级别降到EL1/EL0。为此，我们只需要禁用MMU（因为m1n1假设它是从具有rwx权限的内存页运行的，而我们在启用SPRR的情况下无法做到这一点），然后跳转到payload，最后，在返回之前再次启用MMU。
这使得我们可以很轻松地探测GL2，例如，看看S3_6_C15_C10_3是否就是SPSR_GL2：
>>> u.mrs((3, 6, 15, 10, 3), call=p.gl_call) 0x60000009 >>> u.mrs(SPSR_EL2) 0x60000009
或者，我们可以直接重新运行MSR查找器，但这次是在GL2中：
gxf_regs = find_regs(call=p.gl_call)
print("GXF")
for r in sorted(gxf_regs - all_regs):
print(" %s" % list(r))这样，我们就发现一大堆神秘的新系统寄存器，它们只有在该上下文中才能找到：
GXF [3, 6, 15, 0, 1] [3, 6, 15, 0, 2] [3, 6, 15, 1, 1] [3, 6, 15, 2, 6] [3, 6, 15, 8, 5] [3, 6, 15, 8, 7] [3, 6, 15, 10, 2] [3, 6, 15, 10, 3] [3, 6, 15, 10, 4] [3, 6, 15, 10, 5] [3, 6, 15, 10, 6] [3, 6, 15, 10, 7] [3, 6, 15, 11, 1] [3, 6, 15, 11, 2] [3, 6, 15, 11, 3] [3, 6, 15, 11, 4] [3, 6, 15, 11, 5] [3, 6, 15, 11, 6] [3, 6, 15, 11, 7]
也许以3、6、15、10开头的是GL1，以3、6、15、11开头的是GL2，或者反过来？这很容易搞清楚：只要在EL2中启用SPRR和GXF后，将运行级别下降到EL1，并重新进行同样的实验即可。这一次我们只得到如下所示的新寄存器：
[3, 6, 15, 0, 1] [3, 6, 15, 8, 7] [3, 6, 15, 10, 1] [3, 6, 15, 10, 2] [3, 6, 15, 10, 3] [3, 6, 15, 10, 4] [3, 6, 15, 10, 5] [3, 6, 15, 10, 6] [3, 6, 15, 10, 7]
这意味着3、6、15、10组确实代表EL1寄存器。这一点并不重要，因为M1总是以HCR_EL2.E2H运行，这意味着_EL1寄存器在EL2级别运行时被重定向到_EL2。同样的情况似乎也适用于GL1和GL2寄存器。
我们能不能也搞清楚它们的确切含义呢？幸运的是，一个早期的开源XNU版本含有如下所示的一些名称：
#define KERNEL_MODE_ELR ELR_GL11 #define KERNEL_MODE_FAR FAR_GL11 #define KERNEL_MODE_ESR ESR_GL11 #define KERNEL_MODE_SPSR SPSR_GL11 #define KERNEL_MODE_ASPSR ASPSR_GL11 #define KERNEL_MODE_VBAR VBAR_GL11 #define KERNEL_MODE_TPIDR TPIDR_GL11
我不清楚为什么这些寄存器带有GL11的后缀，但除此之外，它们可以很容易地与上面发现的未知寄存器匹配起来。ASPSR至少包含一个位，它决定了gexit是否应该返回到保护性执行或正常执行。
即使只是这两个扩展，也还有很多未知的寄存器和谜团。如果你想一起玩，就拿起最新的m1n1，看看到底能搞清楚什么:-)
XNU中的SPRR和GXF
最后，我们来考察一下XNU是如何使用这些新功能的。实际上，这里并没有什么可考察的，因为Jonathan已经在一篇文章中介绍了SPR和GXF的使用情况。SPRR只是取代了过去APRR的功能：禁止内核对页面执行写操作，以及禁止它执行PPL代码。
最大的不同在于GXF：不需要精心设计一个修改APRR寄存器的小蹦床函数，只需要设置GXF入口向量：页表权限就会自动翻转，并且，genter就可以直接指向PPL了。
让我们通过查看XNU如何初始化SPR来确认这一点：启动函数通过SPRR将EL1 SPR权限寄存器初始化为0x2020A505F020F0F0。这个代码序列与所有的CPU chicken位纠缠在一起。marcan甚至正确地猜到了写的是什么，并将它们从实际的chicken位序列中剥离出来。
稍后，初始的GL引导代码会将EL1的权限更新为0x2020A506F020F0E0，然后锁定所有内容，以防止进一步的修改。
然后，受保护的执行模式入口点被设置为一个来自正常内核的text区段的函数，并且该函数必须迅速跳转到PPLTEXT的开头位置。PPL入口函数首先会验证SPRR权限的设置是否正确，之后的行为，具体如Jonathan的文章所述。
最后，我们来看看XNU使用的各种SPRR页权限（这里没有显示的条目对所有级别都没有访问权限。在chicken位序列中设置的原始值也将GL权限设为EL级别）：
这一切看起来都很合理。GL的权限可能会被进一步锁定，例如，不允许GL执行常规的内核代码（参见第10项），不允许它访问任何用户数据（参见第7项）。
除此以外，感觉这就像以前的APRR硬件的一个增强版。这些变化不仅使整个系统不容易出错（寄存器可以被锁定，内核->PPL的转换完全通过硬件实现，内核和PPL的异常向量现在被明确的分隔开来），而且更加灵活。APRR过去只能剥离权限，但SPRR现在允许任意重新映射权限——只要不需要rwx页的话。遗憾的是，在Linux中还没有将它用起来。
小结
Apple Silicon通过了两个“秘密”功能，两者可以通过密切协作，来提供额外的防御机制。GXF引入了横向异常级别，称为GL1和GL2，它们使用的页表与相应的EL使用的相同，但具有不同的页面权限。SPRR允许重新定义EL和GL的页表项中的权限位。苹果公司利用这一点在GL中隐藏所有的页表操作代码，并且禁止EL修改任何页表。这有效地引入了一个具有较小攻击面的低开销管理程序，即使在内核模式下运行的代码也可以很好地保护页表。对于本文来说，其中大部分任务可以借助Python和m1n1进行逆向分析。
这对于将Linux移植到M1上并没有什么用处，但是一旦我们将XNU虚拟化，以便追踪其MMIO访问，我们可能就会遇到这种情况。
开放性问题
在EL1中使用Hypervisor.framework时，是否可以启用SPRR和GXF？
是的! Longhorn指出，存在一个com.apple.private.hypervisor.vmapple权限，允许macOS下的EL1虚拟机也使用这些系统寄存器。
SPRR_CONFIG和GXF_CONFIG中的其他位是做什么用的？
启用SPR和GXF有什么其他影响？至少HCR_EL2不再可以从EL2写入，而是需要GL2权限了，我很肯定这绝对不是唯一的区别。
当我们处于保护性执行模式时，中断会被送到哪里？我认为它们会被送到VBAR_GLx，但我还没有确认这一点。
当在EL2中运行时，应该有一个不同的寄存器用于管理EL0的权限，例如HCR_EL2.TGE = 0和HCR_EL2.TGE = 1。也应该有一种方法可以从EL2访问EL1寄存器（类似于常见的._EL12的寄存器）。哪些寄存器可以做到这一点？
marcan已经在一则视频中把它们讲清楚了；现在它们已经被记录在m1n1中。
siguza发现了涉及PAN和WXN的一些晦涩的硬件bugundefined行为——这个问题仍然存在，还是SPRR也有类似的问题？
SPR和GXF代表什么？可能是“shadow permission remap register（影子权限重映射寄存器）”和“guarded execution feature（受保护的执行功能）”。
还没有评论，来说两句吧...