* KASLR support on ARM with Kernel 4.9 and 4.14 @ 2020-09-25 15:03 Pintu Agarwal 2020-09-25 20:26 ` Kees Cook 0 siblings, 1 reply; 12+ messages in thread From: Pintu Agarwal @ 2020-09-25 15:03 UTC (permalink / raw) To: open list, Kernelnewbies, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Russell King - ARM Linux, ard.biesheuvel, arnd, nico, keescook, thgarnie, marc.zyngier, Mark Rutland, tony, matt, dave.martin Hi All, This is regarding the KASLR feature support on ARM for the kernel version 4.9 and 4.14. Is KASLR supported on ARM-32 Linux 4.9 and above ? Is it dependent on CONFIG_RANDOMIZE_BASE or /proc/sys/kernel/randomize_va_space ? Is there any relation between these two? Is the changing kernel symbols (in every boot), only possible if KASLR is enabled, or there is another way it can happen? I have these queries because, In one of the arm-32 devices with Kernel 4.14, I observed that CONFIG_RANDOMIZE_BASE is not available. But /proc/sys/kernel/randomize_va_space is set to 2. However, I also observed that symbol addresses are changing in every boot. 1st boot cycle: [root ~]# cat /proc/kallsyms | grep "sys_open" a5b4de92 T sys_open [root@sa515m ~]# 2nd boot cycle: [root ~]# cat /proc/kallsyms | grep "sys_open" f546ed66 T sys_open So, I am wondering how this is possible without KASLR (CONFIG_RANDOMIZE_BASE) support in Kernel ? Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available but /proc/sys/kernel/randomize_va_space is set to 2. But here, the addresses are remaining same. 1st Run: [root~]# cat /proc/kallsyms | grep "sys_open" c01ed68c T sys_open [root ~]# *** reboot *** [root ~]# cat /proc/kallsyms | grep "sys_open" c01ed68c T sys_open Is there any other difference between these two kernel versions with respect to changing symbol addresses ? Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 15:03 KASLR support on ARM with Kernel 4.9 and 4.14 Pintu Agarwal @ 2020-09-25 20:26 ` Kees Cook 2020-09-25 20:37 ` Ard Biesheuvel 0 siblings, 1 reply; 12+ messages in thread From: Kees Cook @ 2020-09-25 20:26 UTC (permalink / raw) To: Pintu Agarwal Cc: Mark Rutland, arnd, ard.biesheuvel, marc.zyngier, dave.martin, Kernelnewbies, Russell King - ARM Linux, open list, tony, matt, nico, thgarnie, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote: > This is regarding the KASLR feature support on ARM for the kernel > version 4.9 and 4.14. > > Is KASLR supported on ARM-32 Linux 4.9 and above ? Sorry, this feature did not yet land in upstream: https://github.com/KSPP/linux/issues/3 Here was the earlier effort: https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/ > Is it dependent on CONFIG_RANDOMIZE_BASE or CONFIG_RANDOMIZE_BASE is what is used on other architectures to control the feature. > /proc/sys/kernel/randomize_va_space ? > Is there any relation between these two? No, the latter is about userspace addresses. > Is the changing kernel symbols (in every boot), only possible if KASLR > is enabled, or there is another way it can happen? I think you meant kernel symbol addresses (not the symbols themselves). But yes, I wouldn't expect the addresses to move if you didn't either rebuild the kernel or had something else moving the kernel at boot (i.e. the boot loader). > I have these queries because, > In one of the arm-32 devices with Kernel 4.14, I observed that > CONFIG_RANDOMIZE_BASE is not available. > But /proc/sys/kernel/randomize_va_space is set to 2. > However, I also observed that symbol addresses are changing in every boot. > > 1st boot cycle: > [root ~]# cat /proc/kallsyms | grep "sys_open" > a5b4de92 T sys_open > [root@sa515m ~]# > > 2nd boot cycle: > [root ~]# cat /proc/kallsyms | grep "sys_open" > f546ed66 T sys_open > > So, I am wondering how this is possible without KASLR > (CONFIG_RANDOMIZE_BASE) support in Kernel ? What device is this? Is it a stock kernel? > Similarly, with Kernel 4.9 and CONFIG_RANDOMIZE_BASE is not available > but /proc/sys/kernel/randomize_va_space is set to 2. > But here, the addresses are remaining same. > > 1st Run: > [root~]# cat /proc/kallsyms | grep "sys_open" > c01ed68c T sys_open > [root ~]# > > *** reboot *** > [root ~]# cat /proc/kallsyms | grep "sys_open" > c01ed68c T sys_open > > > Is there any other difference between these two kernel versions with > respect to changing symbol addresses ? Is the boot loader changing the base address? (What boot loader are you using?) -- Kees Cook _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 20:26 ` Kees Cook @ 2020-09-25 20:37 ` Ard Biesheuvel 2020-09-25 20:47 ` Kees Cook 0 siblings, 1 reply; 12+ messages in thread From: Ard Biesheuvel @ 2020-09-25 20:37 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Pintu Agarwal, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, Kernelnewbies, Russell King - ARM Linux, open list, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote: > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote: > > This is regarding the KASLR feature support on ARM for the kernel > > version 4.9 and 4.14. > > > > Is KASLR supported on ARM-32 Linux 4.9 and above ? > > Sorry, this feature did not yet land in upstream: > https://github.com/KSPP/linux/issues/3 > > Here was the earlier effort: > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/ > > > Is it dependent on CONFIG_RANDOMIZE_BASE or > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control > the feature. > > > /proc/sys/kernel/randomize_va_space ? > > Is there any relation between these two? > > No, the latter is about userspace addresses. > > > Is the changing kernel symbols (in every boot), only possible if KASLR > > is enabled, or there is another way it can happen? > > I think you meant kernel symbol addresses (not the symbols themselves). > But yes, I wouldn't expect the addresses to move if you didn't either > rebuild the kernel or had something else moving the kernel at boot (i.e. > the boot loader). > > > I have these queries because, > > In one of the arm-32 devices with Kernel 4.14, I observed that > > CONFIG_RANDOMIZE_BASE is not available. > > But /proc/sys/kernel/randomize_va_space is set to 2. > > However, I also observed that symbol addresses are changing in every boot. > > > > 1st boot cycle: > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > a5b4de92 T sys_open > > [root@sa515m ~]# > > > > 2nd boot cycle: > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > f546ed66 T sys_open > > > > So, I am wondering how this is possible without KASLR > > (CONFIG_RANDOMIZE_BASE) support in Kernel ? > Those addresses were obfuscated by kptr_restrict _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 20:37 ` Ard Biesheuvel @ 2020-09-25 20:47 ` Kees Cook 2020-09-25 21:09 ` Ard Biesheuvel 0 siblings, 1 reply; 12+ messages in thread From: Kees Cook @ 2020-09-25 20:47 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, Thomas Garnier, Pintu Agarwal, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, Kernelnewbies, Russell King - ARM Linux, open list, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote: > > > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote: > > > This is regarding the KASLR feature support on ARM for the kernel > > > version 4.9 and 4.14. > > > > > > Is KASLR supported on ARM-32 Linux 4.9 and above ? > > > > Sorry, this feature did not yet land in upstream: > > https://github.com/KSPP/linux/issues/3 > > > > Here was the earlier effort: > > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/ > > > > > Is it dependent on CONFIG_RANDOMIZE_BASE or > > > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control > > the feature. > > > > > /proc/sys/kernel/randomize_va_space ? > > > Is there any relation between these two? > > > > No, the latter is about userspace addresses. > > > > > Is the changing kernel symbols (in every boot), only possible if KASLR > > > is enabled, or there is another way it can happen? > > > > I think you meant kernel symbol addresses (not the symbols themselves). > > But yes, I wouldn't expect the addresses to move if you didn't either > > rebuild the kernel or had something else moving the kernel at boot (i.e. > > the boot loader). > > > > > I have these queries because, > > > In one of the arm-32 devices with Kernel 4.14, I observed that > > > CONFIG_RANDOMIZE_BASE is not available. > > > But /proc/sys/kernel/randomize_va_space is set to 2. > > > However, I also observed that symbol addresses are changing in every boot. > > > > > > 1st boot cycle: > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > a5b4de92 T sys_open > > > [root@sa515m ~]# > > > > > > 2nd boot cycle: > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > f546ed66 T sys_open > > > > > > So, I am wondering how this is possible without KASLR > > > (CONFIG_RANDOMIZE_BASE) support in Kernel ? > > Those addresses were obfuscated by kptr_restrict Is that true? kptr_restrict zeros (rather than hashing) the kallsyms view. And besides, the %p hashing was added in v4.15 (but also doesn't touch kallsyms, which does all-or-nothing to avoid breaking stuff like perf). -- Kees Cook _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 20:47 ` Kees Cook @ 2020-09-25 21:09 ` Ard Biesheuvel 2020-09-25 23:47 ` Kees Cook 0 siblings, 1 reply; 12+ messages in thread From: Ard Biesheuvel @ 2020-09-25 21:09 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Pintu Agarwal, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, Kernelnewbies, Russell King - ARM Linux, open list, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@chromium.org> wrote: > > On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote: > > On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote: > > > > > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote: > > > > This is regarding the KASLR feature support on ARM for the kernel > > > > version 4.9 and 4.14. > > > > > > > > Is KASLR supported on ARM-32 Linux 4.9 and above ? > > > > > > Sorry, this feature did not yet land in upstream: > > > https://github.com/KSPP/linux/issues/3 > > > > > > Here was the earlier effort: > > > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/ > > > > > > > Is it dependent on CONFIG_RANDOMIZE_BASE or > > > > > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control > > > the feature. > > > > > > > /proc/sys/kernel/randomize_va_space ? > > > > Is there any relation between these two? > > > > > > No, the latter is about userspace addresses. > > > > > > > Is the changing kernel symbols (in every boot), only possible if KASLR > > > > is enabled, or there is another way it can happen? > > > > > > I think you meant kernel symbol addresses (not the symbols themselves). > > > But yes, I wouldn't expect the addresses to move if you didn't either > > > rebuild the kernel or had something else moving the kernel at boot (i.e. > > > the boot loader). > > > > > > > I have these queries because, > > > > In one of the arm-32 devices with Kernel 4.14, I observed that > > > > CONFIG_RANDOMIZE_BASE is not available. > > > > But /proc/sys/kernel/randomize_va_space is set to 2. > > > > However, I also observed that symbol addresses are changing in every boot. > > > > > > > > 1st boot cycle: > > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > > a5b4de92 T sys_open > > > > [root@sa515m ~]# > > > > > > > > 2nd boot cycle: > > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > > f546ed66 T sys_open > > > > > > > > So, I am wondering how this is possible without KASLR > > > > (CONFIG_RANDOMIZE_BASE) support in Kernel ? > > > > Those addresses were obfuscated by kptr_restrict > > Is that true? kptr_restrict zeros (rather than hashing) the kallsyms > view. And besides, the %p hashing was added in v4.15 (but also doesn't > touch kallsyms, which does all-or-nothing to avoid breaking stuff > like perf). > Ah yes, good point. But it does look suspiciously like they are being mangled in a similar way. 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 21:09 ` Ard Biesheuvel @ 2020-09-25 23:47 ` Kees Cook 2020-09-26 7:58 ` Pintu Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Kees Cook @ 2020-09-25 23:47 UTC (permalink / raw) To: Ard Biesheuvel Cc: Mark Rutland, Thomas Garnier, Pintu Agarwal, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, Kernelnewbies, Russell King - ARM Linux, open list, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Fri, Sep 25, 2020 at 11:09:10PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@chromium.org> wrote: > > > > On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote: > > > On Fri, 25 Sep 2020 at 22:28, Kees Cook <keescook@chromium.org> wrote: > > > > > > > > On Fri, Sep 25, 2020 at 08:33:59PM +0530, Pintu Agarwal wrote: > > > > > This is regarding the KASLR feature support on ARM for the kernel > > > > > version 4.9 and 4.14. > > > > > > > > > > Is KASLR supported on ARM-32 Linux 4.9 and above ? > > > > > > > > Sorry, this feature did not yet land in upstream: > > > > https://github.com/KSPP/linux/issues/3 > > > > > > > > Here was the earlier effort: > > > > https://lore.kernel.org/kernel-hardening/20170814125411.22604-1-ard.biesheuvel@linaro.org/ > > > > > > > > > Is it dependent on CONFIG_RANDOMIZE_BASE or > > > > > > > > CONFIG_RANDOMIZE_BASE is what is used on other architectures to control > > > > the feature. > > > > > > > > > /proc/sys/kernel/randomize_va_space ? > > > > > Is there any relation between these two? > > > > > > > > No, the latter is about userspace addresses. > > > > > > > > > Is the changing kernel symbols (in every boot), only possible if KASLR > > > > > is enabled, or there is another way it can happen? > > > > > > > > I think you meant kernel symbol addresses (not the symbols themselves). > > > > But yes, I wouldn't expect the addresses to move if you didn't either > > > > rebuild the kernel or had something else moving the kernel at boot (i.e. > > > > the boot loader). > > > > > > > > > I have these queries because, > > > > > In one of the arm-32 devices with Kernel 4.14, I observed that > > > > > CONFIG_RANDOMIZE_BASE is not available. > > > > > But /proc/sys/kernel/randomize_va_space is set to 2. > > > > > However, I also observed that symbol addresses are changing in every boot. > > > > > > > > > > 1st boot cycle: > > > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > > > a5b4de92 T sys_open > > > > > [root@sa515m ~]# > > > > > > > > > > 2nd boot cycle: > > > > > [root ~]# cat /proc/kallsyms | grep "sys_open" > > > > > f546ed66 T sys_open > > > > > > > > > > So, I am wondering how this is possible without KASLR > > > > > (CONFIG_RANDOMIZE_BASE) support in Kernel ? > > > > > > Those addresses were obfuscated by kptr_restrict > > > > Is that true? kptr_restrict zeros (rather than hashing) the kallsyms > > view. And besides, the %p hashing was added in v4.15 (but also doesn't > > touch kallsyms, which does all-or-nothing to avoid breaking stuff > > like perf). > > > > Ah yes, good point. But it does look suspiciously like they are being > mangled in a similar way. > > 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... -- Kees Cook _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-25 23:47 ` Kees Cook @ 2020-09-26 7:58 ` Pintu Agarwal 2020-09-26 16:40 ` Kees Cook 0 siblings, 1 reply; 12+ messages in thread From: Pintu Agarwal @ 2020-09-26 7:58 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Sat, 26 Sep 2020 at 05:17, Kees Cook <keescook@chromium.org> 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). ==> 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 ? -- Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-26 7:58 ` Pintu Agarwal @ 2020-09-26 16:40 ` Kees Cook 2020-09-28 13:45 ` Pintu Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Kees Cook @ 2020-09-26 16:40 UTC (permalink / raw) To: Pintu Agarwal Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Sat, Sep 26, 2020 at 01:28:02PM +0530, Pintu Agarwal wrote: > On Sat, 26 Sep 2020 at 05:17, Kees Cook <keescook@chromium.org> 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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-26 16:40 ` Kees Cook @ 2020-09-28 13:45 ` Pintu Agarwal 2020-09-28 14:11 ` Pintu Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Pintu Agarwal @ 2020-09-28 13:45 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE 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. Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-28 13:45 ` Pintu Agarwal @ 2020-09-28 14:11 ` Pintu Agarwal 2020-09-28 19:50 ` Kees Cook 0 siblings, 1 reply; 12+ messages in thread From: Pintu Agarwal @ 2020-09-28 14:11 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE 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/e63732dbfe017aa0dbabac9d096b5fde8afbd395 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-28 14:11 ` Pintu Agarwal @ 2020-09-28 19:50 ` Kees Cook 2020-09-30 13:58 ` Pintu Agarwal 0 siblings, 1 reply; 12+ messages in thread From: Kees Cook @ 2020-09-28 19:50 UTC (permalink / raw) To: Pintu Agarwal Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Mon, Sep 28, 2020 at 07:41:13PM +0530, Pintu Agarwal wrote: > 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/e63732dbfe017aa0dbabac9d096b5fde8afbd395 That's an out-of-tree patch. The one that was backported to 4.14 from 4.15 that does %p hashing is this one: https://gitlab.com/quicla/kernel/msm-4.14/-/commit/ad67b74d2469d9b82aaa572d76474c95bc484d57 > Are we talking about this? > I cound not find this in 4.9 kernel. Note that I still can't explain what you're seeing. /proc/kallsyms shouldn't be affected by these patches -- I would expect it to either report the true value or 00s. > I will disable kptr_restrict and check or, I will enable > CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check. I would start with kptr_restrict=0 and see if that changes the contents of /proc/kallsyms. If it does, then it is the hashing. If it doesn't, well, we're back to square one. :) -- Kees Cook _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: KASLR support on ARM with Kernel 4.9 and 4.14 2020-09-28 19:50 ` Kees Cook @ 2020-09-30 13:58 ` Pintu Agarwal 0 siblings, 0 replies; 12+ messages in thread From: Pintu Agarwal @ 2020-09-30 13:58 UTC (permalink / raw) To: Kees Cook Cc: Mark Rutland, Thomas Garnier, Arnd Bergmann, Ard Biesheuvel, Marc Zyngier, open list, Kernelnewbies, Russell King - ARM Linux, Ard Biesheuvel, Tony Lindgren, nico, Dave Martin, matt, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On Tue, 29 Sep 2020 at 01:20, Kees Cook <keescook@chromium.org> wrote: > Note that I still can't explain what you're seeing. /proc/kallsyms > shouldn't be affected by these patches -- I would expect it to either > report the true value or 00s. > > > I will disable kptr_restrict and check or, I will enable > > CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS and check. > > I would start with kptr_restrict=0 and see if that changes the contents > of /proc/kallsyms. If it does, then it is the hashing. If it doesn't, > well, we're back to square one. :) Actually in that board, the kptr_restrict=0 already in both case: 4.9 and 4.14 Kernel boards. In another board with 4.14 and kptr_restrict=2, I see that the addresses are 00 always. I further checked that when I enable this config: CONFIG_DEBUG_CONSOLE_UNHASHED_POINTERS, then the addresses are remaining the same in every boot. But this particular config is not present in 4.9 Kernel. So, I think it is controlled using this config. -- Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-09-30 14:01 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-25 15:03 KASLR support on ARM with Kernel 4.9 and 4.14 Pintu Agarwal 2020-09-25 20:26 ` Kees Cook 2020-09-25 20:37 ` Ard Biesheuvel 2020-09-25 20:47 ` Kees Cook 2020-09-25 21:09 ` Ard Biesheuvel 2020-09-25 23:47 ` Kees Cook 2020-09-26 7:58 ` Pintu Agarwal 2020-09-26 16:40 ` Kees Cook 2020-09-28 13:45 ` Pintu Agarwal 2020-09-28 14:11 ` Pintu Agarwal 2020-09-28 19:50 ` Kees Cook 2020-09-30 13:58 ` Pintu Agarwal
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).