arm64 kaslr 开启配置就能用？

在linux平台上构建纵深防御系统的过程中，KASLR（内核地址空间布局随机化）几乎是必须使能的一项重要基础安全功能，多数安全从业人员接触KASLR都是从攻击的角度开始的，对其基本原理和用途多少有些了解，但当我们站在攻击的对立面想要在arm64架构上使能这个功能的时候，我们遇到了一些问题。

在我和我的同事中，有一个很普遍的认识错误，即kaslr的使能就是开启一些配置，配置好了就能正常使用。并且网络上的各种教程也是按照这个流程“成功”使能KASLR，让这种错误的认识广为流传。

按照相关文档的介绍，我们打开了kernel和u-boot相关的配置，如下：

// u-boot启用以下配置
CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y

// kernel启用一下配置
CONFIG_RANDOMIZE_BASE=y

重新编译u-boot和kernel之后，我们多次启动系统，通过检查对比每次启动后内核符号的地址，我们发现KASLR并未生效，因为内核符号地址是同一个值。

发现这个问题之后，我个人进行了一个小小的反思，因为在我的认识里，诸如PAN、PXN和DEP等系统自带的功能，只要开启对应的配置就能使能这些功能，所以在向业务团队提需求的过程中，这种类型的需求基本使用一到两句话轻描淡写，殊不知这样的需求描述可能完全没有可指导落地的价值，到功能验收和测试的时候可能还会埋怨业务团队不重视安全、不积极配合。

由此引发我联想到一个更加普遍的问题，即甲方安全人员如何才能制定出可执行、可落地的安全方案？在这个案例上我得到的启发是，制定安全方案的人，需要对业务有足够多的了解，了解到能够根据业务的真实逻辑来制定安全方案，而不是单方面从安全自身的需求进行脱离业务逻辑的表述，这种表述大概率不符合业务的实际情况，也不会得到业务方的认可。

因此，在KASLR这个案例上，我决定进一步分析arm64实现KASLR的原理。因为我们使用的硬件平台来自NXP，所以相关逻辑可能与其他平台不能完全契合，但大体思路应该都是相似的。

arm64平台实现KASLR的总体思路是通过trustzone运行一个sec firmware，sec firmware会负责生成kaslr-seed，也就是用来计算内核偏移的随机种子。其中，sec firmware的加载工作由u-boot负责执行，u-boot通过ppa（可以理解为trustzone中的一个应用，用来将sec frimware加载到trust总额中运行）将sec firmware（如teeOS.bin）加载到trustzone中运行，然后在fdt_fixup的过程中调用sec firmware生成kaslr-seed，并将这个值设置到对应的fdt。

整个实现思路的安全主旨就是通过trustzone来生成随机数，以保证随机数的安全性，进而保证内核地址的随机性。但在我们使用的平台上没有实现trustzone，ppa也不会生成和运行，因而导致虽然我们开启了必须的配置，但实际的业务逻辑并不支持KASLR的运行，所以必须在现有平台上重新构建安全地生成随机数的逻辑。