近日在给NDB增加新功能，让它可以访问用户空间。但在ARM平台上遇到一个问题，如果CPU中断时位于内核空间，那么访问任何用户空间的地址都失败。

失败的基本症状是调试器中打印出一串串的问号。

而JTAG库打印出如下错误信息：abort occurred - dscr = 0x03047d47

其中的dscr是ARM CoreSight技术中定义的外部调试寄存器，全称为EDSCR，即外部调试状态和控制寄存器，在ARMv8架构手册中可以找到它的详细定义，结合上面的错误码，解读如下图所示。

本以为低6位的状态值部分可以给出错误原因，但是却始终给出的是“断点”含意，意思是这一次中断到调试器是因为遇到断点。

请老朋友使用ARM官方的DTRACE工具进行测试，也发现类似情况，某些情况下无法读用户空间。比如下图中，当切换到5号CPU后，再访问其它核可以访问的一段地址空间，访问失败，内存窗口显示红色背景，没有数据。

下图是正常能读的情况。

是谁在阻止强大的硬件调试器访问内存呢？根据多年的经验，可能是安全机制在搞鬼。但是这个鬼藏在哪里呢？

今日周末，又想起这个问题。想到了以前在写“猫蛇大战”系列时读过的Linux内核uaccess代码。

虽然内核空间具有高特权，从特权级别来说可以访问用户空间。但其实真的要访问的话，还是有一些复杂的。首先用户空间有很多个，用户空间的内存常常不在物理内存中，另外，内核访问用户空间也要有正当的理由，不可以“擅闯民宅”。所以内核访问用户空间时，也可谓是如履薄冰。

另外，因为这部分逻辑与CPU硬件相关，所以代码也很分散。实现时又常常用宏或者嵌入式汇编，读起来也比较难读。

想到这里，我便打开内核代码，搜索uaccess，搜索整个内核代码树得到的结果太多了，只搜索GDK8使用的arch/arm64。这样一搜，果然有收获。处理页错误的一行printk引起了我的注意。

die_kernel_fault("access to user memory outside uaccess routines",

addr, esr, regs);

这个die系列打印是内核里的一道景观。一执行到这个函数，系统就进入panic了。品味这个错误信息：“在uaccess过程外访问用户内存”，这是调用die的理由，也就是给系统判死刑的原因。

顺着这条消息思考：在uaccess之外不可以访问用户内存。NDB显然属于这种情况啊。因为NDB是用JTAG来访问内存，不是用uaccess。

那么为什么uaccess就能访问呢？

打开arm64下的uaccess代码，很快找到了一个关键函数。

__uaccess_ttbr0_disable，从这个函数名来看，是要禁止访问，“坏事”多半就是它干的。

这个函数上面有个条件编译选项，查这个选项，果然是打开的。

geduer@gdk8:~$ zcat /proc/config.gz | grep TTBR0

CONFIG_ARM64_SW_TTBR0_PAN=y

如此看来就是它在捣鬼。搜索这个宏的文档：

Emulate Privileged Access Never using TTBR0_EL1 switching

configname: CONFIG_ARM64_SW_TTBR0_PAN

Linux Kernel Configuration

└─> Kernel Features

└─> Emulate Privileged Access Never using TTBR0_EL1 switching

Enabling this option prevents the kernel from accessing

user-space memory directly by pointing TTBR0_EL1 to a reserved

zeroed area and reserved ASID. The user access routines

restore the valid TTBR0_EL1 temporarily.

写的很清楚，为了防止内核空间随便访问用户空间，故意把记录用户空间页目录的ttbr0寄存器偷梁换柱了。这招真够损的。^-^

使用ndb读ttbr0寄存器，看到的是这样一个值：

rdmsr ttbr0_el1

msr[182000] = 00000000`02503000

剧透一下，这个值就是假冒的，和后面将看到的有效值差别很大。

既然是uaccess函数做的禁止，那么它也该有方法来启用啊，诚然如此。

阅读这个函数的代码，它是从当前线程信息中读到保存的ttbr0，然后再写到物理CPU中。

如何找到保存的ttbr值呢？

有办法。在NDB中先执行!ps命令显示当前线程的task_struct地址。

task_struct:0xffffffc0f409e740 pid:  179  comm:avahi-daemon

PGD:0xffffffc0f0d2b000 CR3=0x0

state 0 flags:0x404100 stack:0xffffff800b8a8000

上面的地址指向的就是Linux下每个线程都有的task_struct结构体，内核源代码中常常使用著名的current宏来访问（我将其称为Linux内核第一霸）。这个结构体极其庞大，它的起始部分就是架构相关的thread_info子结构。

dt lk!task_struct

+0x000 thread_info      : thread_info

+0x020 state            : Int8B

+0x028 stack            : Ptr64 Void

+0x030 usage            :

+0x034 flags            : Uint4B

+0x038 ptrace           : Uint4B

+0x040 wake_entry       : llist_node

+0x048 on_cpu           : Int4B

+0x04c cpu              : Uint4B

+0x050 wakee_flips      : Uint4B

+0x058 wakee_flip_decay_ts : Int8B

+0x060 last_wakee       : Ptr64 task_struct

【此处省略数百行】

既然thread_info就在task_struct的开头，那么task_struct的地址就是thread_info的地址。使用dt命令观察：

dt lk!thread_info 0xffffffc0f409e740

+0x000 flags            : 0

+0x008 addr_limit       : 549755813887

+0x010 ttbr0            : 0xf80000`f0d2b000

+0x018 preempt_count    : 0

果然，真实的ttbr0现身了。

接下来，使用NDB的写寄存器命令把这个保存的ttbr0写给CPU：

wrmsr ttbr0_el1 0xf80000f0d2b000

再读回来确认：

rdmsr ttbr0_el1

msr[182000] = 00f80000`f0d2b000

确认ttbr0写成功后，再尝试访问用户空间：

dd 0000007f`82809000

0000007f`82809000  464c457f 00010102 00000000 00000000

0000007f`82809010  00b70003 00000001 000011c0 00000000

0000007f`82809020  00000040 00000000 0001e548 00000000

0000007f`82809030  00000000 00380040 00400007 0019001a

0000007f`82809040  00000001 00000005 00000000 00000000

0000007f`82809050  00000000 00000000 00000000 00000000

0000007f`82809060  0001c4d4 00000000 0001c4d4 00000000

0000007f`82809070  00010000 00000000 00000001 00000006

居然就成功了，困扰多日的问题就这么解决了，在解决的过程中，年轻的NDB调试器和挥码枪发挥了积极作用。给它们个合影吧。

我是在旅途中写的这篇文章。GDK8和挥码枪都很方便携带，所以我就把他们放在背包中，随时可以取出来，快速搭建起一个强大的调试环境。

上图中的蓝色配件叫Nano Display，它可以把GDK8的HDMI输出转为USB信号，送给笔记本电脑，Nano Code中集成了一个视频播放功能，可以把GDK8的桌面显示在主机上。

GDK8的桌面是我深爱的庐山秀峰之龙潭。很多格友曾经与我同游过。

（写文章很辛苦，恳请各位读者点击“在看”，也欢迎转发）

*************************************************

正心诚意，格物致知，以人文情怀审视软件，以软件技术改变人生

扫描下方二维码或者在微信中搜索“盛格塾”小程序，可以文章和有声读物

也欢迎关注格友公众号