On Sat, Sep 26, 2020 at 01:28:02PM +0530, Pintu Agarwal wrote: > On Sat, 26 Sep 2020 at 05:17, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > > > > > > For a 3/1 split ARM kernel of the typical size, all kernel virtual > > > addresses start with 0xc0, and given that the kernel is located at the > > > start of the linear map, those addresses cannot change even if you > > > move the kernel around in physical memory. > > > > I wonder if this is an Android Common kernel? I think there was %p > > hashing in there before v4.15, but with a different implementation... > > > > Hi, > Thank you all for all your reply and comments so far! > Here are some follow-up replies. > > >> What device is this? Is it a stock kernel? > This is a Qualcomm Snapdragon Automotive board one with Linux Kernel > 4.9 and one with 4.14. > > >> Is the boot loader changing the base address? (What boot loader are you > >> using?) > Ohh I did not knew that the bootloader can also change the base address. > I think it uses UEFI. > How to check if bootloader is doing this ? > BTW, both 4.9 board and 4.14 board, uses same bootloader. > > >> 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. :) -- Kees Cook _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
