On Mon, 28 Sep 2020 at 19:15, Pintu Agarwal <pintu.ping@gmail.com> wrote:
On Sat, 26 Sep 2020 at 22:10, Kees Cook <keescook@chromium.org> wrote:
I wonder if this is an Android Common kernel? It uses the below kernel for 4.14: https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or similar branch).
Okay, so yes. And this appears to have the hashing of %p backported. I cannot, however, explain why it's showing hashed pointers instead of just NULL, though.
It might be related to these commits but they're not in that kernel: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers")
==> The case where symbol addresses are changing.
kptr_restrict is set to 2 by default: / # cat /proc/sys/kernel/kptr_restrict 2
Basically, the goal is: * To understand how addresses are changing in 4.14 Kernel (without KASLR support)? * Is it possible to support the same in 4.9 Kernel ?
Try setting kptr_restrict to 0 and see if the symbol addresses change? I suspect Ard is correct: there's no KASLR here, just hashed pointers behaving weird on an old non-stock kernel. :)
Okay. Thank you so much for your comments and suggestions. You mean to say, setting kptr_restrict to 0 may avoid changing symbol addresses in 4.14 ? And, sorry, I could not understand the thing about this "hashed pointers". How can I check this behavior in source code to understand better? Is it possible to give some reference ? I wanted to disable this hash pointer on 4.14 kernel and check the behavior. Also if possible, we would like to make this similar change on 4.9 kernel as well.
Okay, I found these changes in 4.14 kernel: https://gitlab.com/quicla/kernel/msm-4.14/-/commit/e63732dbfe017aa0dbabac9d0... Are we talking about this? I cound not find this in 4.9 kernel. I will disable kptr_restrict and check or, I will enable CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check. Thanks, Pintu