linux-kernel - Re: KASLR support on ARM with Kernel 4.9 and 4.14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXEWutwE-fP9bc=tsyPoTuV6J7bLzLpkZ213P9y9JszkTw@mail.gmail.com>
Date:   Fri, 25 Sep 2020 23:09:10 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Pintu Agarwal <pintu.ping@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Dave Martin <dave.martin@....com>,
        Kernelnewbies <kernelnewbies@...nelnewbies.org>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        open list <linux-kernel@...r.kernel.org>,
        Tony Lindgren <tony@...mide.com>, matt@...eblueprint.co.uk,
        nico@...aro.org, Thomas Garnier <thgarnie@...gle.com>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14

On Fri, 25 Sep 2020 at 22:47, Kees Cook <keescook@...omium.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@...omium.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@...15m ~]#
> > > >
> > > > 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.