Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1411883pxk; Fri, 25 Sep 2020 14:11:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyeXDU8MjDI5dOlNeJWMPVsyAoUJy+WArzwnXJE6rjYBGirZpRgWATWHBb99hPmzaFWXYoq X-Received: by 2002:a17:906:fb8f:: with SMTP id lr15mr4606593ejb.25.1601068263450; Fri, 25 Sep 2020 14:11:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601068263; cv=none; d=google.com; s=arc-20160816; b=znZ3T3Sy18HsuxusQCch7JPC2hGXOGauNgSDxOcVkZDzR1o/PK+tfqJWyxJzO4btNB 9Xvxw2VBtkd+vAAA5HwnGbqXGq7ccXFkosB1dKf6YTFDfbtq7BbzD84+jZovIEqJuWeh 88dwof86qL3K00lsX6LGduUTO4kzUuFoW0xOSCFxhDQ0mC8GKH0kkRskxVv4eykv8ujx gkwKfWViwpdfqh50K0QD7wK9JyQfMiUC92E+KcFjDM9hbIH47TDECPy6WQsFf6URWQGk TiLyFFA+21UpN544cSrwnF0/acLxzAgTFOR/rmz5jIQCTwj59t7suGayHzVs7bt+gmwm Zx0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=88OnxH8Vyd74g0UFkhcjwnzHM47ASZZ812ZbPggXg+8=; b=m2VLbnfh8L46HAhMZVOM8dR8cRwIRdQT7tliAKle0acE2oY3/NoEDx5en9zBmT1rnO JLqWTEcywnIrf7CmPQz9ayMXntpSlCQpn2/NDtn7Y+iM4fwER+ELWIYNB/KVu5QntxZ1 A7ZerU/VhGUsh/cHBaZzDvViPrMiXBXUlBCdzwHuVre/fOgspCQ4d6G7J2OuPp0PyVPT Lw8man5j5xZQzxEmFzBwBEAMSzWqrPnPt0gOpWXE8rp5J+Hd6xSq3RZJx1WkhH4gJBhi kLmH+bRujIBFblclpE8WMtso5F3VQVCCNRfA++gIhBU97XyFCvn/Q/59gBn3q3fViGYF jG+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=nAc35Ob5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rv15si2676151ejb.364.2020.09.25.14.10.40; Fri, 25 Sep 2020 14:11:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=nAc35Ob5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727324AbgIYVJW (ORCPT + 99 others); Fri, 25 Sep 2020 17:09:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:58536 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726309AbgIYVJW (ORCPT ); Fri, 25 Sep 2020 17:09:22 -0400 Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DF974239EC for ; Fri, 25 Sep 2020 21:09:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601068162; bh=88OnxH8Vyd74g0UFkhcjwnzHM47ASZZ812ZbPggXg+8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nAc35Ob5odDDVZgfuI+99lsW9yc2bEzQJ8X74n6tyUFMGWatOOnc6PcdERXE6M79y H1oxXYWIenrpxVUaZ0u9Wz1lByM5nVR1C3h2N6wVOF4jL1jXGixs3ECxPhstQcOeu9 pppBBvnvymSFxI29y7Jp7SeGXKQ5cO9hM0A6so2M= Received: by mail-oo1-f42.google.com with SMTP id m25so1099345oou.0 for ; Fri, 25 Sep 2020 14:09:21 -0700 (PDT) X-Gm-Message-State: AOAM533mqOURcylb74MkQEcM8PD7a/c535tv+q+M+9JamEl7y166UVHP dJ3VzPaYXdRZLcWhjoit1Yb4ciW323YnpeIj1JM= X-Received: by 2002:a4a:c541:: with SMTP id j1mr2155634ooq.13.1601068161083; Fri, 25 Sep 2020 14:09:21 -0700 (PDT) MIME-Version: 1.0 References: <202009251301.A1FD183582@keescook> <202009251338.D17FB071@keescook> In-Reply-To: <202009251338.D17FB071@keescook> From: Ard Biesheuvel Date: Fri, 25 Sep 2020 23:09:10 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14 To: Kees Cook Cc: Pintu Agarwal , Mark Rutland , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , Dave Martin , Kernelnewbies , Russell King - ARM Linux , open list , Tony Lindgren , matt@codeblueprint.co.uk, nico@linaro.org, Thomas Garnier , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 25 Sep 2020 at 22:47, Kees Cook wrote: > > On Fri, Sep 25, 2020 at 10:37:01PM +0200, Ard Biesheuvel wrote: > > On Fri, 25 Sep 2020 at 22:28, Kees Cook 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.