Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1867046ybl; Wed, 28 Aug 2019 23:28:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyXFaH1/71EQQASlX78Y7WKK5OomfEaNye/zK3q9C1m0RxdkbgXO+aTBwTSi70a08YA4QAY X-Received: by 2002:a62:2aca:: with SMTP id q193mr9472773pfq.209.1567060103610; Wed, 28 Aug 2019 23:28:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567060103; cv=none; d=google.com; s=arc-20160816; b=kXy0JZzHP7Oh5G7GT1KcTcRb+6kmPY08zhmS9m0MG0uyX5wCmZ0EIJyhl6MSNPjSXi qjZzZV1AJmQ322bEMM3tGw/0iiQHHscAAZA6+jn1LxiuQY889UdRpG0MdWTFKn7KPGNv cItbIjR6pa7aouVKksiUCOaOI0s5r0jths0p0bmc1QqfLRfncXnzxqTmgh6seq/IVhfL 5qQ71At4TFHEpayMpV08OTMcZlwK1I/qdaPqwomPd6zgqnHBwv2d3P4oRtl16e682IOa B1+Y0dkJw1sXK+EHSkn7zWVzy1I/0JqCIX0lg7+Wf7g5CrkdOvlSjHLqTXfwcZ5mjMbP lOrg== 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=NdTsxVLYtAHcKivJYIh+J9VJhanxs7KW3Xgf0GelawI=; b=W2zNGV1T1oIBvItpJWzXUm/UKtUfmgGym4JaeeGe2XZ2tlzgKJQaXEeRQx5T2ApQYV r8zFP5Ydu+tz+7sY9i/2ygbVBGvMsFc7A725D+uaZ4nyug1nX2QCpPx5SWKd8br6N9/O hKH0shwMaHsE3Z0p4Y7FnczYBKPo3Z05DyO/rapYQYXLqW6sWZp40rDKuEV1ZnMOhzhO Wg7XGXaSgnLyvYEcYZppHZ4llSmbcQY9VgHckEgOEw5KNLZG2ebW2oTG4SADP3hG3BVV 8GV+uPUQAGbZyTKJiTBg95BcqSSPDwC7mi6jERoGXkUJNLWAFdqocJLepWPScK37xn5p HNxg== 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 a141si1663245pfd.49.2019.08.28.23.28.08; Wed, 28 Aug 2019 23:28:23 -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 S1727421AbfH2G1D (ORCPT + 99 others); Thu, 29 Aug 2019 02:27:03 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:53382 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726016AbfH2G1D (ORCPT ); Thu, 29 Aug 2019 02:27:03 -0400 Received: from DGGEMS408-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id B5D623BD6BCA87A6F7C9; Thu, 29 Aug 2019 14:26:58 +0800 (CST) Received: from [127.0.0.1] (10.177.96.203) by DGGEMS408-HUB.china.huawei.com (10.3.19.208) with Microsoft SMTP Server id 14.3.439.0; Thu, 29 Aug 2019 14:26:49 +0800 Subject: Re: [PATCH v6 06/12] powerpc/fsl_booke/32: implement KASLR infrastructure To: Christophe Leroy , Scott Wood CC: , , , , , , , , , , , , , , References: <20190809100800.5426-1-yanaijie@huawei.com> <20190809100800.5426-7-yanaijie@huawei.com> <20190828045454.GB17757@home.buserror.net> <2db76c55-df5f-5ca8-f0a6-bcee75b8edaa@c-s.fr> From: Jason Yan Message-ID: <11ef88f7-e418-c48e-f96c-1256c1179bca@huawei.com> Date: Thu, 29 Aug 2019 14:26:47 +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: <2db76c55-df5f-5ca8-f0a6-bcee75b8edaa@c-s.fr> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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/28 13:47, Christophe Leroy wrote: > > > Le 28/08/2019 à 06:54, Scott Wood a écrit : >> On Fri, Aug 09, 2019 at 06:07:54PM +0800, Jason Yan wrote: >>> 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. >>> >>> The offset of the kernel was not randomized yet(a fixed 64M is set). We >>> will randomize it in the next patch. >>> >>> Signed-off-by: Jason Yan >>> Cc: Diana Craciun >>> Cc: Michael Ellerman >>> Cc: Christophe Leroy >>> Cc: Benjamin Herrenschmidt >>> Cc: Paul Mackerras >>> Cc: Nicholas Piggin >>> Cc: Kees Cook >>> Tested-by: Diana Craciun >>> Reviewed-by: Christophe Leroy >>> --- >>>   arch/powerpc/Kconfig                          | 11 ++++ >>>   arch/powerpc/kernel/Makefile                  |  1 + >>>   arch/powerpc/kernel/early_32.c                |  2 +- >>>   arch/powerpc/kernel/fsl_booke_entry_mapping.S | 17 +++-- >>>   arch/powerpc/kernel/head_fsl_booke.S          | 13 +++- >>>   arch/powerpc/kernel/kaslr_booke.c             | 62 +++++++++++++++++++ >>>   arch/powerpc/mm/mmu_decl.h                    |  7 +++ >>>   arch/powerpc/mm/nohash/fsl_booke.c            |  7 ++- >>>   8 files changed, 105 insertions(+), 15 deletions(-) >>>   create mode 100644 arch/powerpc/kernel/kaslr_booke.c >>> > > [...] > >>> diff --git a/arch/powerpc/kernel/kaslr_booke.c >>> b/arch/powerpc/kernel/kaslr_booke.c >>> new file mode 100644 >>> index 000000000000..f8dc60534ac1 >>> --- /dev/null >>> +++ b/arch/powerpc/kernel/kaslr_booke.c >> >> Shouldn't this go under arch/powerpc/mm/nohash? >> >>> +/* >>> + * To see if we need to relocate the kernel to a random offset >>> + * void *dt_ptr - address of the device tree >>> + * phys_addr_t size - size of the first memory block >>> + */ >>> +notrace void __init kaslr_early_init(void *dt_ptr, phys_addr_t size) >>> +{ >>> +    unsigned long tlb_virt; >>> +    phys_addr_t tlb_phys; >>> +    unsigned long offset; >>> +    unsigned long kernel_sz; >>> + >>> +    kernel_sz = (unsigned long)_end - KERNELBASE; >> >> Why KERNELBASE and not kernstart_addr? >> >>> + >>> +    offset = kaslr_choose_location(dt_ptr, size, kernel_sz); >>> + >>> +    if (offset == 0) >>> +        return; >>> + >>> +    kernstart_virt_addr += offset; >>> +    kernstart_addr += offset; >>> + >>> +    is_second_reloc = 1; >>> + >>> +    if (offset >= SZ_64M) { >>> +        tlb_virt = round_down(kernstart_virt_addr, SZ_64M); >>> +        tlb_phys = round_down(kernstart_addr, SZ_64M); >> >> If kernstart_addr wasn't 64M-aligned before adding offset, then "offset >>> = SZ_64M" is not necessarily going to detect when you've crossed a >> mapping boundary. >> >>> + >>> +        /* Create kernel map to relocate in */ >>> +        create_tlb_entry(tlb_phys, tlb_virt, 1); >>> +    } >>> + >>> +    /* Copy the kernel to it's new location and run */ >>> +    memcpy((void *)kernstart_virt_addr, (void *)KERNELBASE, kernel_sz); >>> + >>> +    reloc_kernel_entry(dt_ptr, kernstart_virt_addr); >>> +} >> >> After copying, call flush_icache_range() on the destination. > > Function copy_and_flush() does the copy and the flush. I think it should > be used instead of memcpy() + flush_icache_range() > Hi Christophe, Thanks for the suggestion. But I think copy_and_flush() is not included in fsl booke code, maybe move this function to misc.S? > Christophe > > . >