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 C1C2EC432BE for ; Mon, 26 Jul 2021 19:02:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7494F60F5D for ; Mon, 26 Jul 2021 19:02:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7494F60F5D 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 1291C8D0001; Mon, 26 Jul 2021 15:02:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B2B96B0036; Mon, 26 Jul 2021 15:02:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EBC4F8D0001; Mon, 26 Jul 2021 15:02:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id CD4AC6B0033 for ; Mon, 26 Jul 2021 15:02:48 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 78C5E8249980 for ; Mon, 26 Jul 2021 19:02:48 +0000 (UTC) X-FDA: 78405660816.30.F8812D8 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by imf18.hostedemail.com (Postfix) with ESMTP id C9FB64001E92 for ; Mon, 26 Jul 2021 19:02:47 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id 5C852296; Mon, 26 Jul 2021 21:02:46 +0200 (CEST) Date: Mon, 26 Jul 2021 21:02:44 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C9FB64001E92 Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.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: uksmw3pqfd6c57doy6a5ydqpiqmsp8qc X-HE-Tag: 1627326167-873633 Content-Transfer-Encoding: quoted-printable 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 Thu, Jul 22, 2021 at 05:46:13PM +0200, David Hildenbrand wrote: > +1, this smells like an anti-patter. I'm absolutely not in favor of a > bitmap, we have the sparse memory model for a reason. Well, I doubt that TDX or SNP guests will be set up with a sparse memory layout. > Also, I am not convinced that kexec/kdump is actually easy to realize w= ith > the bitmap? > Who will forward that bitmap? The kernel decompressor will create it and forward it to the decompressed kernel image. The running kernel will pass it on to kexec'ed kernels for the lifetime of the system. > Where will it reside? In Linux kernel owned memory, location decided by the kernel decompressor. >Who says it's not corrupted? If the hypervisor corrupts it we can notice it. The guest kernel can corrupt it on its own, but that is true for all data in the guest, also the memmap. > Just take a look at how we don't even have access to memmap of the > oldkernel in the newkernel -- and have to locate and decipher it in > constantly-to-be-updated user space makedumpfile. Any time you'd > change anything about the bitmap ("hey, let's use larger chunks", > "hey, let's split it up") you'd break the old_kernel > <-> new_kernel agreement. Im not sure if makedumpfile needs to know about that bitmap. If we mirror the same information into the memmap, then there is definitly no need for it. Regards, J=F6rg