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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202009251338.D17FB071@keescook>
Date:   Fri, 25 Sep 2020 13:47:22 -0700
From:   Kees Cook <keescook@...omium.org>
To:     Ard Biesheuvel <ardb@...nel.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, 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).

-- 
Kees Cook

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ