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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E133C433EF for ; Tue, 19 Apr 2022 18:32:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDF406B0071; Tue, 19 Apr 2022 14:32:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E673B6B0073; Tue, 19 Apr 2022 14:32:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE0EC6B0074; Tue, 19 Apr 2022 14:32:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id B7F0D6B0071 for ; Tue, 19 Apr 2022 14:32:39 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 82E9A2530F for ; Tue, 19 Apr 2022 18:32:39 +0000 (UTC) X-FDA: 79374474438.08.00344E8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf04.hostedemail.com (Postfix) with ESMTP id D3ADB40011 for ; Tue, 19 Apr 2022 18:32:37 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 1BD1461536 for ; Tue, 19 Apr 2022 18:32:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E2EB8C385A5 for ; Tue, 19 Apr 2022 18:32:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650393157; bh=md0tG2V1t23ZnRlqUCm/DSQwwQtpFcWbjxl5FLEoEv4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=flFM69QagDkSdAXYtqe4qYSD6ro/lEoxTn0UF+tJrzr2ZdTNtRQgtcQ3CGj+raw9j u6xP3vuYANtn0AsgSTjXTJ3qT/RQfWpXqiRw0BniUYCL5AdVa4WTPUsTGuN2ctkUFW OR6gQZ5e2gi23hq8GHqlvUy07L6MvYpeuE1oET06Txj6Pf6xSxUpelXcT4HOrS7Oun avDuoRLBqKiJeFi0FSetF8HJbkKp7ijzxoWFc/nayEIFiBlsi4VBOTLgCBSohe4N1x c9owXRx+THxq21w1YOitgpS5pgoMWhux7ZxagbDJigfQNZ5y9h5SrrkVB6DkJafZhF P2yC72ZAuW1dw== Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-e5ca5c580fso8113879fac.3 for ; Tue, 19 Apr 2022 11:32:37 -0700 (PDT) X-Gm-Message-State: AOAM532kIP/oCF0ZXh+JbqLtOHcZazQeKBryFlNdeVIElOXmTRlcl8Y0 QM/UQvC0WIiSAJXzmfcKx7YmaLsLQsL7ljX7cXQ= X-Google-Smtp-Source: ABdhPJy+tDK9eGCepkKXeOvvfKeb4HZc+BluW5/5YJu1JhLSn0xWy3QnFC8BRtKUY0f9PpybIp3EFNlsyXbWugc+Hn4= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr9290611oap.228.1650393146846; Tue, 19 Apr 2022 11:32:26 -0700 (PDT) MIME-Version: 1.0 References: <20220414101314.1250667-1-mawupeng1@huawei.com> <6de859df-e1c3-e9aa-4530-3b61b9c69a28@huawei.com> In-Reply-To: <6de859df-e1c3-e9aa-4530-3b61b9c69a28@huawei.com> From: Ard Biesheuvel Date: Tue, 19 Apr 2022 20:32:15 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/9] introduce mirrored memory support for arm64 To: mawupeng Cc: Andrew Morton , Catalin Marinas , Will Deacon , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , hpa@zyccr.com, Darren Hart , Andy Shevchenko , Mike Rapoport , "Paul E. McKenney" , Peter Zijlstra , Joerg Roedel , songmuchun@bytedance.com, macro@orcam.me.uk, Frederic Weisbecker , W_Armin@gmx.de, John Garry , Sean Christopherson , Thomas Bogendoerfer , Anshuman Khandual , chenhuacai@kernel.org, David Hildenbrand , gpiccoli@igalia.com, Mark Rutland , Kefeng Wang , Linux Doc Mailing List , Linux Kernel Mailing List , Linux ARM , linux-efi , linux-ia64@vger.kernel.org, platform-driver-x86@vger.kernel.org, Linux Memory Management List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=flFM69Qa; spf=pass (imf04.hostedemail.com: domain of ardb@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: b5uqainpoen5rijabii5agyrh5q3ofu8 X-Rspamd-Queue-Id: D3ADB40011 X-Rspamd-Server: rspam04 X-Rspam-User: X-HE-Tag: 1650393157-696352 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, 16 Apr 2022 at 03:32, mawupeng wrote: > > > > =E5=9C=A8 2022/4/14 18:22, Ard Biesheuvel =E5=86=99=E9=81=93: > > On Thu, 14 Apr 2022 at 11:54, Wupeng Ma wrote: > >> > >> From: Ma Wupeng > >> > >> Commit b05b9f5f9dcf ("x86, mirror: x86 enabling - find mirrored memory= ranges") > >> introduced mirrored memory support for x86. This support rely on UEFI = to > >> report mirrored memory address ranges. See UEFI 2.5 spec pages 157-15= 8: > >> > >> http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf > >> > >> Memory mirroring is a technique used to separate memory into two separ= ate > >> channels, usually on a memory device, like a server. In memory mirrori= ng, > >> one channel is copied to another to create redundancy. This method mak= es > >> input/output (I/O) registers and memory appear with more than one addr= ess > >> range because the same physical byte is accessible at more than one > >> address. Using memory mirroring, higher memory reliability and a highe= r > >> level of memory consolidation are possible. > >> > >> Arm64 can support this too. So mirrored memory support is added to sup= port > >> arm64. > >> > >> Efi_fake_mem is used for testing mirrored features and will not be use= d in > >> production environment. This test features can fake memory's attribute > >> values. > >> > >> The reason why efi_fake_mem support is put first is that memory's attr= ibute > >> is reported by BIOS which is hard to simulate. With this support, any = arm64 > >> machines with efi support can easily test mirrored features. > >> > >> The main purpose of this patchset is to introduce mirrored support for > >> arm64 and we have already fixed the problems we had which is shown in > >> patch #5 to patch #7 and try to bring total isolation in patch #8 whic= h > >> will disable mirror feature if kernelcore is not specified. > >> > >> In order to test this support in arm64: > >> - patch this patchset > >> - add efi_fake_mem=3D8G@0:0x10000 in kernel parameter to simulate mirr= ored > >> memroy between phy addr 0-8G. > >> - add kernelcore=3Dmirror in kernel parameter > >> - start you kernel > >> > > > > As I explained before: > > > > - NAK to EFI fake_mem support on arm64 > > fake_mem support on arm64 will be removed in subsequent version. > > > - NAK to the whole series until you come up with a proposal on how to > > locate the static kernel image itself into more reliable memory, as > > there is really no point to any of this otherwise. > > Sorry I am not familiar with this, as you metioned before, > > > you have to iterate over the memory map and look for regions with > > the desired attribute, and allocate those pages explicitly. > > Do you mean this is x86, commit c05cd79750fb > ("x86/boot/KASLR: Prefer mirrored memory regions for the kernel physical = address"). > I will do some research. > > > I'd prefer to implement this in the bootloader, and only add minimal > > logic to the stub to respect the placement of the kernel by the loader > > if the loader signals it to do so. > > Does this bootloader refer to grub and then add minimal logic to arm64-st= ub.c? > Any bootloader, yes. > What is the loader signal? A protocol installed onto the image handle, as I suggested before. I even cc'ed you on a patch that implements this. > System exists mirrored memory reported by uefi? > What on earth is the point of any of this if the only use case being targeted is efi_fake_mem with arbitrary fake mirrored regions? So yes, unless there are systems that need this, I don't see a point in merging any of this.