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.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 12C74C2D0A8 for ; Mon, 28 Sep 2020 13:45:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF76120E65 for ; Mon, 28 Sep 2020 13:45:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BNVdcEwm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726595AbgI1Npg (ORCPT ); Mon, 28 Sep 2020 09:45:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33332 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726409AbgI1Npg (ORCPT ); Mon, 28 Sep 2020 09:45:36 -0400 Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD7D6C061755 for ; Mon, 28 Sep 2020 06:45:35 -0700 (PDT) Received: by mail-ej1-x644.google.com with SMTP id p15so8565073ejm.7 for ; Mon, 28 Sep 2020 06:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=BNVdcEwmKLu7UYdR5qEDszaHp8AwI5/LgsYb7Hsdtjf7D6i3k7AeC78Jo/GaShyX40 PQp0zwjoAscJL836jYurIzDYfagXQ9Q2Q3zMYgBzhS6uPDvLnRht11A1HYT5uLviDzlq zfTbKGWHeztMEoUQt0x6zGuswkmdnfDRKnVUODUGJoa42OebAGOLt9f1TRaOUqn3/pUo yo8QuGFykfpZdiU2PziKjCdLoAt4hVRr+wdmIGvw0LMT+UeyOML9+2iPZegCefE5jsGW 7G7kwdnV88wpbmLrdHWwxe1C9ck44FX6rUFcXAjWeiSbTW4wgKmSTA7vtbdaNvTamRCF uDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=PZhbtZc8KdMY2k+Pzn9np7S4X6uJOXeMcjPczLq7ziirZmddgN4aP/ToQX9UC9QJOc uxd9GJF0kQePk+MyyKPpukzCFVo0O4x3cPp4vnMgTUYt/FWawrhv68JMOkYRwFPwgo3b SBsQUGi6975NbaTbvMwGKQEvWjfbyI8MP7UuyAmFVtEz64pXRgDVWXQB7gIV08DzeAaQ ny9LhlYd2qOxo1j7GBlePOBP1TN5WezOGUZNO8JoqM+q5CKVUysACdL4dTpZ6AigNIvF 9G2MF8elOfuLjg6pPRjmjia0HG+Ii0r13GW+D0hapXPyzLonUX9sdrXHEraHelaYNcjE WNtA== X-Gm-Message-State: AOAM531+jT50CM07QMV0OfEunjoz3+mdyYvtXA0JI4Wtz/sSihmX0kq1 nOomRldgsISfdRyTrnro+0GrY7E3XNl+I1hDKYc= X-Google-Smtp-Source: ABdhPJyUtjxTt6+MXoHHOw+wBmFQ0H6ldEi6lU+XXFNWOxLIdQofZk+MD8H9mvrP4gIxCYsb4i63/1jUgoRiERxUheE= X-Received: by 2002:a17:906:e24d:: with SMTP id gq13mr1671104ejb.152.1601300734379; Mon, 28 Sep 2020 06:45:34 -0700 (PDT) MIME-Version: 1.0 References: <202009251301.A1FD183582@keescook> <202009251338.D17FB071@keescook> <202009251647.FD8CECD4@keescook> <202009260933.C603CD8@keescook> In-Reply-To: <202009260933.C603CD8@keescook> From: Pintu Agarwal Date: Mon, 28 Sep 2020 19:15:23 +0530 Message-ID: Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14 To: Kees Cook Cc: Ard Biesheuvel , 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 Sat, 26 Sep 2020 at 22:10, Kees Cook wrote: > > >> I wonder if this is an Android Common kernel? > > It uses the below kernel for 4.14: > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or > > similar branch). > > Okay, so yes. And this appears to have the hashing of %p backported. I > cannot, however, explain why it's showing hashed pointers instead of > just NULL, though. > > It might be related to these commits but they're not in that kernel: > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers") > > > ==> The case where symbol addresses are changing. > > > > kptr_restrict is set to 2 by default: > > / # cat /proc/sys/kernel/kptr_restrict > > 2 > > > > Basically, the goal is: > > * To understand how addresses are changing in 4.14 Kernel (without > > KASLR support)? > > * Is it possible to support the same in 4.9 Kernel ? > > Try setting kptr_restrict to 0 and see if the symbol addresses change? I > suspect Ard is correct: there's no KASLR here, just hashed pointers > behaving weird on an old non-stock kernel. :) > Okay. Thank you so much for your comments and suggestions. You mean to say, setting kptr_restrict to 0 may avoid changing symbol addresses in 4.14 ? And, sorry, I could not understand the thing about this "hashed pointers". How can I check this behavior in source code to understand better? Is it possible to give some reference ? I wanted to disable this hash pointer on 4.14 kernel and check the behavior. Also if possible, we would like to make this similar change on 4.9 kernel as well. Thanks, Pintu 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.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 A81ECC2D0A8 for ; Mon, 28 Sep 2020 13:47:24 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 2B38D208FE for ; Mon, 28 Sep 2020 13:47:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="xFouiBiq"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BNVdcEwm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B38D208FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oNNCH5hZRTaFX4z9MWJcKwQJyLtRjwZp5bgSzLffHUM=; b=xFouiBiqBEW57bOWAFTz1nOll 3GShr2iPOlx8QKiyNg4b7T4Ccd9+v6WtZBD+jEjCWGLUc7Eosb+QBrXQZafnlx2EHm0kwAKFaZNRh LHa7+jtwGUiCiZ3Bi0i8vIKssyp/PuNb6bmqoAVJOfAHTXgrm/MKb2mQJvUn29wL8kCfZaC8QrriK rtpfPkMKC2V2/e3KfTtOush+4h7Tm/2nT59Wimgg9rxzvCMRydK7iv9s1IwRpcXM2BJ2nbmp++LvO GMZfCbI6Yrzo85YhzHj5lxTG01pEF1mNLbq5o9jr07RHHhIHnNq0KcZ0X8NcVguxAKnFmYvSd8sVm bQVV71KAg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMtTI-00074Y-C9; Mon, 28 Sep 2020 13:45:40 +0000 Received: from mail-ej1-x644.google.com ([2a00:1450:4864:20::644]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMtTF-000740-Hu for linux-arm-kernel@lists.infradead.org; Mon, 28 Sep 2020 13:45:38 +0000 Received: by mail-ej1-x644.google.com with SMTP id q13so8552275ejo.9 for ; Mon, 28 Sep 2020 06:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=BNVdcEwmKLu7UYdR5qEDszaHp8AwI5/LgsYb7Hsdtjf7D6i3k7AeC78Jo/GaShyX40 PQp0zwjoAscJL836jYurIzDYfagXQ9Q2Q3zMYgBzhS6uPDvLnRht11A1HYT5uLviDzlq zfTbKGWHeztMEoUQt0x6zGuswkmdnfDRKnVUODUGJoa42OebAGOLt9f1TRaOUqn3/pUo yo8QuGFykfpZdiU2PziKjCdLoAt4hVRr+wdmIGvw0LMT+UeyOML9+2iPZegCefE5jsGW 7G7kwdnV88wpbmLrdHWwxe1C9ck44FX6rUFcXAjWeiSbTW4wgKmSTA7vtbdaNvTamRCF uDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=B9Ohudi2RvcWnN5d4/HnK2+g0uvA0ZL6ZDE2wi518l3psFxfnUG5/HdBhWwEEtNCgQ YSYZvDPoBvx88OQgrQE3/OOq/0Vz5Z4ln1MyZn+oQJaww9YnoHN8w17W149FuadQgkX2 2RxbiMXYfNbDzkXKbkI+4KKd/SDKGVzP73z8AeLWUKn9MDB3zf6nDNT0pB67LnQpH8CE AhdYy1yWkNCX/PP7rHtPqgMKnWTkKWPUU0HAgNojje+Ga6M0NLDJAzThw5oYHX/FSQjx ILJImuKFA89wzYwPokvH0a8UXbZ/+CwR1jz2NgRaOMH4+efJEoaDdKjNIj5oWq4s/FS2 D7cw== X-Gm-Message-State: AOAM531XbG1V2cNL4TIkfSHfYyCVbkwV007FuWvZMJEZnJmPzBP2xXDC vf7Hl7SLNBBo7U+zQS4dnVsKbB40jDYciBTKxrw= X-Google-Smtp-Source: ABdhPJyUtjxTt6+MXoHHOw+wBmFQ0H6ldEi6lU+XXFNWOxLIdQofZk+MD8H9mvrP4gIxCYsb4i63/1jUgoRiERxUheE= X-Received: by 2002:a17:906:e24d:: with SMTP id gq13mr1671104ejb.152.1601300734379; Mon, 28 Sep 2020 06:45:34 -0700 (PDT) MIME-Version: 1.0 References: <202009251301.A1FD183582@keescook> <202009251338.D17FB071@keescook> <202009251647.FD8CECD4@keescook> <202009260933.C603CD8@keescook> In-Reply-To: <202009260933.C603CD8@keescook> From: Pintu Agarwal Date: Mon, 28 Sep 2020 19:15:23 +0530 Message-ID: Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14 To: Kees Cook X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200928_094537_645180_F95FAC94 X-CRM114-Status: GOOD ( 22.75 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Thomas Garnier , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , open list , Kernelnewbies , Russell King - ARM Linux , Ard Biesheuvel , Tony Lindgren , nico@linaro.org, Dave Martin , matt@codeblueprint.co.uk, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 26 Sep 2020 at 22:10, Kees Cook wrote: > > >> I wonder if this is an Android Common kernel? > > It uses the below kernel for 4.14: > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or > > similar branch). > > Okay, so yes. And this appears to have the hashing of %p backported. I > cannot, however, explain why it's showing hashed pointers instead of > just NULL, though. > > It might be related to these commits but they're not in that kernel: > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers") > > > ==> The case where symbol addresses are changing. > > > > kptr_restrict is set to 2 by default: > > / # cat /proc/sys/kernel/kptr_restrict > > 2 > > > > Basically, the goal is: > > * To understand how addresses are changing in 4.14 Kernel (without > > KASLR support)? > > * Is it possible to support the same in 4.9 Kernel ? > > Try setting kptr_restrict to 0 and see if the symbol addresses change? I > suspect Ard is correct: there's no KASLR here, just hashed pointers > behaving weird on an old non-stock kernel. :) > Okay. Thank you so much for your comments and suggestions. You mean to say, setting kptr_restrict to 0 may avoid changing symbol addresses in 4.14 ? And, sorry, I could not understand the thing about this "hashed pointers". How can I check this behavior in source code to understand better? Is it possible to give some reference ? I wanted to disable this hash pointer on 4.14 kernel and check the behavior. Also if possible, we would like to make this similar change on 4.9 kernel as well. Thanks, Pintu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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.3 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 79737C2D0A8 for ; Mon, 28 Sep 2020 13:46:10 +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 DE570208FE for ; Mon, 28 Sep 2020 13:46:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BNVdcEwm" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE570208FE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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 1kMtTH-0005wQ-Cv; Mon, 28 Sep 2020 09:45:39 -0400 Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kMtTF-0005wG-03 for kernelnewbies@kernelnewbies.org; Mon, 28 Sep 2020 09:45:37 -0400 Received: by mail-ej1-x641.google.com with SMTP id p9so8580710ejf.6 for ; Mon, 28 Sep 2020 06:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=BNVdcEwmKLu7UYdR5qEDszaHp8AwI5/LgsYb7Hsdtjf7D6i3k7AeC78Jo/GaShyX40 PQp0zwjoAscJL836jYurIzDYfagXQ9Q2Q3zMYgBzhS6uPDvLnRht11A1HYT5uLviDzlq zfTbKGWHeztMEoUQt0x6zGuswkmdnfDRKnVUODUGJoa42OebAGOLt9f1TRaOUqn3/pUo yo8QuGFykfpZdiU2PziKjCdLoAt4hVRr+wdmIGvw0LMT+UeyOML9+2iPZegCefE5jsGW 7G7kwdnV88wpbmLrdHWwxe1C9ck44FX6rUFcXAjWeiSbTW4wgKmSTA7vtbdaNvTamRCF uDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0oYLNU2owXItYr9P/AcypoLK4YHCnMHvEUEZ0T21Kmw=; b=LJ07/7gbXn66GVBBSx5u/FfTl8Va2CPvu0h4cc9aMUtt838967QXaI6S/sXrYcb8ex H/kyOXwdehlYcxaLx7plqqw3rp95KHrrz5ujv0nLgHrYfuwwv7SqQgpZoPjkENwoWClv /xCUl/66RWFATJ6MLsq62DZnt1iV/8TcQQc9AGguFl7yiQgRRIZHapasj6rmZbVjchc4 EgWPcyxCJiP2TiF5Zs7Zz5UfU7FJN0Q6jrYiocXExj279AGs9JRaYeO4OGP47F/htBf/ XuVSu1dxFBdhdjv64x+CvKQx4Oe1E6DQE9ubs0u/MgIZnMWBrUNSPo75aYXdZYzu5mdj FetA== X-Gm-Message-State: AOAM530jvcpGSUX5k5sg1QCp8IBbA6KExK1T4gn7p78Y4HcJb5QfmTno 1qcC3ICLy4fA9zaVHbcvgijXBowKZtsIWRkFBx8= X-Google-Smtp-Source: ABdhPJyUtjxTt6+MXoHHOw+wBmFQ0H6ldEi6lU+XXFNWOxLIdQofZk+MD8H9mvrP4gIxCYsb4i63/1jUgoRiERxUheE= X-Received: by 2002:a17:906:e24d:: with SMTP id gq13mr1671104ejb.152.1601300734379; Mon, 28 Sep 2020 06:45:34 -0700 (PDT) MIME-Version: 1.0 References: <202009251301.A1FD183582@keescook> <202009251338.D17FB071@keescook> <202009251647.FD8CECD4@keescook> <202009260933.C603CD8@keescook> In-Reply-To: <202009260933.C603CD8@keescook> From: Pintu Agarwal Date: Mon, 28 Sep 2020 19:15:23 +0530 Message-ID: Subject: Re: KASLR support on ARM with Kernel 4.9 and 4.14 To: Kees Cook Cc: Mark Rutland , Thomas Garnier , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , open list , Kernelnewbies , Russell King - ARM Linux , Ard Biesheuvel , 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 Sat, 26 Sep 2020 at 22:10, Kees Cook wrote: > > >> I wonder if this is an Android Common kernel? > > It uses the below kernel for 4.14: > > https://gitlab.com/quicla/kernel/msm-4.14/-/tree/LE.UM.3.4.2.r1.5 (or > > similar branch). > > Okay, so yes. And this appears to have the hashing of %p backported. I > cannot, however, explain why it's showing hashed pointers instead of > just NULL, though. > > It might be related to these commits but they're not in that kernel: > 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") > 7bd57fbc4a4d ("vsprintf: don't obfuscate NULL and error pointers") > > > ==> The case where symbol addresses are changing. > > > > kptr_restrict is set to 2 by default: > > / # cat /proc/sys/kernel/kptr_restrict > > 2 > > > > Basically, the goal is: > > * To understand how addresses are changing in 4.14 Kernel (without > > KASLR support)? > > * Is it possible to support the same in 4.9 Kernel ? > > Try setting kptr_restrict to 0 and see if the symbol addresses change? I > suspect Ard is correct: there's no KASLR here, just hashed pointers > behaving weird on an old non-stock kernel. :) > Okay. Thank you so much for your comments and suggestions. You mean to say, setting kptr_restrict to 0 may avoid changing symbol addresses in 4.14 ? And, sorry, I could not understand the thing about this "hashed pointers". How can I check this behavior in source code to understand better? Is it possible to give some reference ? I wanted to disable this hash pointer on 4.14 kernel and check the behavior. Also if possible, we would like to make this similar change on 4.9 kernel as well. Thanks, Pintu _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies