From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28A52C4727C for ; Tue, 29 Sep 2020 18:18:32 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 50C5B208B8 for ; Tue, 29 Sep 2020 18:18:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="qNb+YYrX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50C5B208B8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1kNKC7-0007U4-Rj; Tue, 29 Sep 2020 14:17:43 -0400 Received: from mail.kernel.org ([198.145.29.99]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1kLuSw-0004s1-Eo for kernelnewbies@kernelnewbies.org; Fri, 25 Sep 2020 16:37:14 -0400 Received: from mail-oo1-f50.google.com (mail-oo1-f50.google.com [209.85.161.50]) (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 B804E23730 for ; Fri, 25 Sep 2020 20:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601066232; bh=WZbwT2IHsLPVib9LWqjiQ9VL5NAX2HL7HRcoYiVNWkw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=qNb+YYrX1jzXjp9FjsAl2BzlcqEssgXd1+vfLdR4Xy44/ZcEKjpTebtcmPhIR1H14 qDu+TTbe/P+cWMxj4asNU+S7SegNTtpQqbd6Hlro7NTGLUHUaDM1UjbykZJgEMz5f3 AEWddnez0BlRcuPJXCE4x3QDSn8sKiuW2OWoAzXo= Received: by mail-oo1-f50.google.com with SMTP id r4so1066488ooq.7 for ; Fri, 25 Sep 2020 13:37:12 -0700 (PDT) X-Gm-Message-State: AOAM530Hyxs4Z1oE9642xUdW5Fv94t8KNqbqJNwwRGnWvacnv3OjLTYY oNrBYiQSb1UXuWzX8dnnY5DP6y4578e5N7mAeOE= X-Google-Smtp-Source: ABdhPJy5yn+k2qTffdPEkwz81q4jfUywaUdKX4eyqIezGZqX1pvY0kQk58CIUkInD4MoUX3cSwW3s41Wr8o4wcTAQO8= X-Received: by 2002:a4a:4910:: with SMTP id z16mr2063269ooa.41.1601066231895; Fri, 25 Sep 2020 13:37:11 -0700 (PDT) MIME-Version: 1.0 References: <202009251301.A1FD183582@keescook> In-Reply-To: <202009251301.A1FD183582@keescook> From: Ard Biesheuvel Date: Fri, 25 Sep 2020 22:37:01 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14 To: Kees Cook X-Mailman-Approved-At: Tue, 29 Sep 2020 14:17:21 -0400 Cc: Mark Rutland , Thomas Garnier , Pintu Agarwal , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , Kernelnewbies , Russell King - ARM Linux , open list , Tony Lindgren , nico@linaro.org, Dave Martin , matt@codeblueprint.co.uk, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org 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 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies