On Fri, Sep 25, 2020 at 11:09:10PM +0200, Ard Biesheuvel wrote: > On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxx/ > > > > > > > > > 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@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
