Received: by 2002:a25:b794:0:0:0:0:0 with SMTP id n20csp6416448ybh; Wed, 7 Aug 2019 23:41:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqyLz6MgA28ibtJGJPqUiiTHuels4NXxs+YQZnd4AISFgNLR1k8QzjX+YkA2p67mxwV/iBc0 X-Received: by 2002:a63:714a:: with SMTP id b10mr11723866pgn.25.1565246500479; Wed, 07 Aug 2019 23:41:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565246500; cv=none; d=google.com; s=arc-20160816; b=ldyAoGGunfrOeTPQmzKQVF7ztPWAWOcTLCkk5gRt17uGQFhBADUAlOu5rbAE2IfQBt s1VXtD2PD+qRQU0bJlpWRvQQOv2FzbdAL8/KFES37cTQnY7XAxs10m+xrsmfKXuHUzfS nW9nOv6RseT/1pZBwPwfAu37AKnyiCTFbfctDeA7AX+hHQjm+lrLVv/5M/2kSCHkW2om yLO2BkRhV9eOpvQufIDfAWy+y15JMp+fNdEMVVZ3/QaWKnKtf5DdqSvxyZkNVW/5xYnt A5+DMhnzS1y534SHCg63nZQYYzEx73D2REEkWQAI6nTKuTNuj6UlNKEfAVfmF7A5gXYZ MgQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=yh9q8GJVXhVwjOMyqh7u1DMdEBzv1wntiEb4m0JKksE=; b=TqxIRN0tfnbS011L8fau3g4JTCs17xzZ0lFWtIi43NYzXCPcmIR8j76tty5tuDX6qV b+2kaKTgEahoLa0R0NYLA/1Mogw6CkDlERDp4r4EjuZytWk/wDXnNWK1kmpJFwjCLoiA hY/LZbxYi5p2cSPwF4e+1Q5+JMTzq3P/3i8JPBpqmXSp5cHHczRmtfJUOsq2w6upyIcs 7w4fchOFY62Yt0E1VFI4moJNrveYbHDP5ZNoeaeEwdYFnlXukqCPrJ/mRW2sfHRCFlpt Rgr45TnZKu9K0NSIR3nXiF6Q0NvEMCuWUm3dHDnL1QZHfoDuGG8wJcjbGIhA3UN4qzMb HUTQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a94si1197873pje.19.2019.08.07.23.41.23; Wed, 07 Aug 2019 23:41:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731013AbfHHGUK (ORCPT + 99 others); Thu, 8 Aug 2019 02:20:10 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3782 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725796AbfHHGUK (ORCPT ); Thu, 8 Aug 2019 02:20:10 -0400 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 2CFD9A4BD70DAB1C1172; Thu, 8 Aug 2019 14:20:09 +0800 (CST) Received: from [127.0.0.1] (10.177.96.203) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.439.0; Thu, 8 Aug 2019 14:20:00 +0800 Subject: Re: [PATCH v5 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure To: Michael Ellerman , , , , , , , , CC: , , , , , , References: <20190807065706.11411-1-yanaijie@huawei.com> <20190807065706.11411-7-yanaijie@huawei.com> <87wofpt9dm.fsf@concordia.ellerman.id.au> From: Jason Yan Message-ID: <9a47e042-8994-273f-0622-bdb4d7661668@huawei.com> Date: Thu, 8 Aug 2019 14:19:58 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <87wofpt9dm.fsf@concordia.ellerman.id.au> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.96.203] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/8/7 21:04, Michael Ellerman wrote: > Jason Yan writes: >> This patch add support to boot kernel from places other than KERNELBASE. >> Since CONFIG_RELOCATABLE has already supported, what we need to do is >> map or copy kernel to a proper place and relocate. Freescale Book-E >> parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1 >> entries are not suitable to map the kernel directly in a randomized >> region, so we chose to copy the kernel to a proper place and restart to >> relocate. > > So to be 100% clear you are randomising the location of the kernel in > virtual and physical space, by the same amount, and retaining the 1:1 > linear mapping. > 100% right :) >> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig >> index 77f6ebf97113..755378887912 100644 >> --- a/arch/powerpc/Kconfig >> +++ b/arch/powerpc/Kconfig >> @@ -548,6 +548,17 @@ config RELOCATABLE >> setting can still be useful to bootwrappers that need to know the >> load address of the kernel (eg. u-boot/mkimage). >> >> +config RANDOMIZE_BASE >> + bool "Randomize the address of the kernel image" >> + depends on (FSL_BOOKE && FLATMEM && PPC32) >> + select RELOCATABLE > > I think this should depend on RELOCATABLE, rather than selecting it. > >> diff --git a/arch/powerpc/kernel/kaslr_booke.c b/arch/powerpc/kernel/kaslr_booke.c >> new file mode 100644 >> index 000000000000..30f84c0321b2 >> --- /dev/null >> +++ b/arch/powerpc/kernel/kaslr_booke.c >> @@ -0,0 +1,84 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (C) 2019 Jason Yan >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. > > You don't need that paragraph now that you have the SPDX tag. > > Rather than using a '//' comment followed by a single line block comment > you can format it as: > > // SPDX-License-Identifier: GPL-2.0-only > // > // Copyright (C) 2019 Jason Yan > > >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include > > Do you really need all those headers? > I will remove useless headers. >> +extern int is_second_reloc; > > That should be in a header. > > Any reason why it isn't a bool? > Oh yes, it should be in a header. This variable is already defined before and also used in assembly code. I think it was not defined as a bool just because there is no 'bool' in assembly code. > cheers > > > . >