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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 A7630C4338F for ; Mon, 2 Aug 2021 10:19:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 297D860F6D for ; Mon, 2 Aug 2021 10:19:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 297D860F6D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B0BAA6B0033; Mon, 2 Aug 2021 06:19:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ABAC66B0036; Mon, 2 Aug 2021 06:19:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D05B8D0001; Mon, 2 Aug 2021 06:19:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 85A486B0033 for ; Mon, 2 Aug 2021 06:19:23 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3ACD6180AD81D for ; Mon, 2 Aug 2021 10:19:23 +0000 (UTC) X-FDA: 78429743406.39.69208BB Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by imf04.hostedemail.com (Postfix) with ESMTP id 8DF045001060 for ; Mon, 2 Aug 2021 10:19:22 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 8E19B379; Mon, 2 Aug 2021 12:19:20 +0200 (CEST) Date: Mon, 2 Aug 2021 12:19:15 +0200 From: Joerg Roedel To: David Hildenbrand Cc: "Kirill A. Shutemov" , Joerg Roedel , David Rientjes , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Andi Kleen , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: References: <20210720173004.ucrliup5o7l3jfq3@box.shutemov.name> <023d2435-8cc7-dc44-6258-4135136ddfba@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <023d2435-8cc7-dc44-6258-4135136ddfba@redhat.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8DF045001060 Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of joro@8bytes.org designates 81.169.241.247 as permitted sender) smtp.mailfrom=joro@8bytes.org; dmarc=pass (policy=none) header.from=8bytes.org X-Stat-Signature: jd4seubkd1idbeqsa99osywskz6ei3fr X-HE-Tag: 1627899562-841675 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 Tue, Jul 27, 2021 at 11:34:47AM +0200, David Hildenbrand wrote: > What makes you think that? I already heard people express desires for memory > hot(un)plug, especially in the context of running containers inside > encrypted VMs. And static bitmaps are naturally a bad choice for changing > memory layouts. In the worst case some memory in the bitmap is wasted when memory is hot-unplugged. The amount depends on how much memory one bit covers, but I don't see this as a show stopper. > How will the second kernel figure out the location? Similar to how we pass > the physical address of the vmcore header via the cmdline to the new kernel? As I wrote in the initial proposal, the bitmap will be passed via boot_params. > Okay, owned by the old kernel, not initially mapped by new kernel in the > identity mapping. Is there a prototype/code that implements that? No, besides the prototype patch which Kirill sent around. > Yes, but it does not affect the kdump kernel booting, only makedumpfile > might bail out later when it detects a corruption. > > I'm wondering, why exactly would a kdump kernel (not touching memory of the > old kernel while booting up) need access to the bitmap? Just wondering, for > ACPI tables and such? I can understand why makedumpfile would need that > information when actually dumping memory of the old kernel, but it would > have access to the memmap of the old kernel to obtain that information. The kdump kernel needs the bitmap to detect when the Hypervisor is doing something malicious, well, at least on its own memory. The kdump kernel has full access to the previous kernels memory and could also be tricked by the Hypervisor to reveal secrets. > Mirroring is a good point. But I'd suggest using the bitmap only during > early boot if really necessary and after syncing it to the bitmap, get rid > of it. Sure, kexec is more challenging, but at least it's a clean design. We > can always try expressing the state of validated memory in the e820 map we > present to the kexec kernel. It depends on how fragmented the validated/unvalidated regions will get over time. I think currently it is not very fragmented, the biggest shared regions are the .bss_decrypted section and the DMA bounce buffer. But there are also a couple of page-size regions which need to be shared. For kexec these regions can be validated again when tearing down the APs, but for kdump it would be too fragile to do such extensive stuff before jumping the the kdump kernel. Regards, Joerg