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=-5.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 73AB7C4338F for ; Tue, 27 Jul 2021 09:34:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D7B0A610D0 for ; Tue, 27 Jul 2021 09:34:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D7B0A610D0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 459056B0036; Tue, 27 Jul 2021 05:34:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 409E86B005D; Tue, 27 Jul 2021 05:34:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D12D6B006C; Tue, 27 Jul 2021 05:34:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 136F56B0036 for ; Tue, 27 Jul 2021 05:34:54 -0400 (EDT) Received: from smtpin35.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9707B182646E6 for ; Tue, 27 Jul 2021 09:34:53 +0000 (UTC) X-FDA: 78407858466.35.5794225 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id DEE613000243 for ; Tue, 27 Jul 2021 09:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627378492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x/cFvdqN4Xj3DXMYOW7cFjJJMvqSl7T8o3BRKuSQ8nA=; b=Lhcn4O/vKoF8NJBIre51Eqcu3+RPNcJ1fPxzmd0h8mJU9d+ibZ8vC7aWbzuLDhamOwd/EW 1mI5WimfmuyiOANA9dpqRU0bc9nGJ0DEH0++wacyjI07q8gnF+ItavhbmMrinvGC1xSsnp dWsy4UwUjqjEd4Q5Arz6vdddPiAWPIE= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-216-1SEwXr_DPeuDo8u7EWjBxg-1; Tue, 27 Jul 2021 05:34:50 -0400 X-MC-Unique: 1SEwXr_DPeuDo8u7EWjBxg-1 Received: by mail-wr1-f70.google.com with SMTP id r17-20020adfda510000b02901526f76d738so5816904wrl.0 for ; Tue, 27 Jul 2021 02:34:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=x/cFvdqN4Xj3DXMYOW7cFjJJMvqSl7T8o3BRKuSQ8nA=; b=hx/MqsiMQ/tggLJgGi+clfpvoz9ZwanoL1yV9t0fgBfnfYY5Wy8VD/ZUMxxCYuWAN6 hXVBbgT2PtmW3SJcI0Wgaciu45G7ZVD4zYnCvF6ltf0sR3W5H5KSyI314l3mQ2/ubIYK G6YUDU0/X7q/dynLjgxw52RedHJsdgZgc92eqTx6RtaWfrfRuH5oS5/KoKL9pRSmXVud wTHsfYrAy0y4iYalmqd1QYPNVoC54UeQRRHCdWrFU0P97EL0U1OJd0/Ndh17Aq7W+jxu ON9fFuHB5xAq82TF3/O6ruQJIX2pj00DeuoOTyXCyUwhvxLcJeYpnwWX6co+xt3Qu9+C gijA== X-Gm-Message-State: AOAM533ib6x56QW8zZZrlhGQCtrxPuh7oSCxcOMjNHZv/oZhOhNxBSHG kyvKmvyYXKXTDNGO73IXtgOQpgnN61ybamDdRqGTjTpFqBXrIA6vZzIcUaKD/dE5KW1OTBL69v3 TFvZoi7RvfVM= X-Received: by 2002:adf:b605:: with SMTP id f5mr23592941wre.419.1627378489512; Tue, 27 Jul 2021 02:34:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMhj+gPGT7Vs/guH6NirDuDBBJ1uaMH6gd689xxXSmfgwWK++/1jGSao4aWIp6ioeNMcszyQ== X-Received: by 2002:adf:b605:: with SMTP id f5mr23592900wre.419.1627378489249; Tue, 27 Jul 2021 02:34:49 -0700 (PDT) Received: from [192.168.3.132] (p4ff23c36.dip0.t-ipconnect.de. [79.242.60.54]) by smtp.gmail.com with ESMTPSA id b6sm3204580wrn.9.2021.07.27.02.34.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jul 2021 02:34:48 -0700 (PDT) To: Joerg Roedel 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 References: <20210720173004.ucrliup5o7l3jfq3@box.shutemov.name> From: David Hildenbrand Organization: Red Hat Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <023d2435-8cc7-dc44-6258-4135136ddfba@redhat.com> Date: Tue, 27 Jul 2021 11:34:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: DEE613000243 Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Lhcn4O/v"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf08.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: a34c1e4ygk7fafaxeqj38c5o6fm7e9zm X-HE-Tag: 1627378492-827078 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 26.07.21 21:02, Joerg Roedel wrote: > 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. >=20 > Well, I doubt that TDX or SNP guests will be set up with a sparse memor= y > layout. What makes you think that? I already heard people express desires for=20 memory hot(un)plug, especially in the context of running containers=20 inside encrypted VMs. And static bitmaps are naturally a bad choice for=20 changing memory layouts. >=20 >> Also, I am not convinced that kexec/kdump is actually easy to realize = with >> the bitmap? >=20 >> Who will forward that bitmap? >=20 > 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. How will the second kernel figure out the location? Similar to how we=20 pass the physical address of the vmcore header via the cmdline to the=20 new kernel? >=20 >> Where will it reside? >=20 > In Linux kernel owned memory, location decided by the kernel > decompressor. Okay, owned by the old kernel, not initially mapped by new kernel in the=20 identity mapping. Is there a prototype/code that implements that? >=20 >> Who says it's not corrupted? >=20 > 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. Yes, but it does not affect the kdump kernel booting, only makedumpfile=20 might bail out later when it detects a corruption. I'm wondering, why exactly would a kdump kernel (not touching memory of=20 the old kernel while booting up) need access to the bitmap? Just=20 wondering, for ACPI tables and such? I can understand why makedumpfile=20 would need that information when actually dumping memory of the old=20 kernel, but it would have access to the memmap of the old kernel to=20 obtain that information. >=20 >> 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. >=20 > 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. Mirroring is a good point. But I'd suggest using the bitmap only during=20 early boot if really necessary and after syncing it to the bitmap, get=20 rid of it. Sure, kexec is more challenging, but at least it's a clean=20 design. We can always try expressing the state of validated memory in=20 the e820 map we present to the kexec kernel. --=20 Thanks, David / dhildenb