StsHostTestCases kptr_restrict 为0分析

StsHostTestCases kptr_restrict 为0

--该词条未被审核

Android Q，202009的STS工具测试STS fail 三项

分析：

查看log：

测试中会cat /proc/sys/kernel/kptr_restrict，期望返回2或者大于2

然后再进行安全补丁的验证。

 

1.STS测试fail先查看补丁是否打上，经过确认，补丁已经打上。

例如某个补丁，查看代码已经存在。

2.那么此项fail的原因为userdebug版本节点/proc/sys/kernel/kptr_restrict的值为0.查看之前的版本（测试pass的版本），一直都是这个值。推测是谷歌工具更新，测试项更新。

kptr_restrict简介：

kptr_restrict:

This toggle indicates whether restrictions are placed on
exposing kernel addresses via /proc and other interfaces.

When kptr_restrict is set to (0), the default, there are no restrictions.

When kptr_restrict is set to (1), kernel pointers printed using the %pK
format specifier will be replaced with 0's unless the user has CAP_SYSLOG
and effective user and group ids are equal to the real ids. This is
because %pK checks are done at read() time rather than open() time, so
if permissions are elevated between the open() and the read() (e.g via
a setuid binary) then %pK will not leak kernel pointers to unprivileged
users. Note, this is a temporary solution only. The correct long-term
solution is to do the permission checks at open() time. Consider removing
world read permissions from files that use %pK, and using dmesg_restrict
to protect against uses of %pK in dmesg(8) if leaking kernel pointer
values to unprivileged users is a concern.

When kptr_restrict is set to (2), kernel pointers printed using
%pK will be replaced with 0's regardless of privileges.

正常情况下userdebug版本这个节点的值为0，是为了调试。并不是bug。但是google STS需要此项为2或者大于2，那么我们需要修改。

 

3.根据高通的case，修改为：

1.remove：CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS

2.回退这个修改：
https://source.codeaurora.org/quic/la/device/qcom/common/commit/?id=dabbf8107e5a90630af568027f11e806e61113ce