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.1 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 8DFF1C4338F for ; Mon, 2 Aug 2021 18:47:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DDC00610FE for ; Mon, 2 Aug 2021 18:47:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DDC00610FE 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 488EB6B0033; Mon, 2 Aug 2021 14:47:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 412386B0036; Mon, 2 Aug 2021 14:47:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B2AB8D0001; Mon, 2 Aug 2021 14:47:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0104.hostedemail.com [216.40.44.104]) by kanga.kvack.org (Postfix) with ESMTP id 0A9B36B0033 for ; Mon, 2 Aug 2021 14:47:40 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 95AD0181AEF2A for ; Mon, 2 Aug 2021 18:47:39 +0000 (UTC) X-FDA: 78431024238.28.F6EC919 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 3464DF0017E3 for ; Mon, 2 Aug 2021 18:47:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627930058; 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=+tUKWkMeQsSWEtCeAubGhlT01HSrUGdhuY5cfxhdFAc=; b=dQk3PxT2mMRxgDfIjefLdVjQf4B5IYVOVBB8W1w97fUE/h+MNqE5LWCcjvnSTPGDupiLSZ n3GyjfFVpxlV3M43MSsr+M9tIU3CB4ZrcYS3LMoGL6+cxitfoBHAyIubd3I7eiN8gVgbHM M0lgXs3vKUvRXTb0v/wdJNgzk294Vwc= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-23-Cx0Aw5N0PqSrepMXXqHeYA-1; Mon, 02 Aug 2021 14:47:37 -0400 X-MC-Unique: Cx0Aw5N0PqSrepMXXqHeYA-1 Received: by mail-wr1-f69.google.com with SMTP id u11-20020a5d434b0000b029013e2027cf9aso6734998wrr.9 for ; Mon, 02 Aug 2021 11:47:37 -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=+tUKWkMeQsSWEtCeAubGhlT01HSrUGdhuY5cfxhdFAc=; b=c21UkuK4kgem2bOhoIhqqCs0g8JgZaQKEnzpDPvGpbyOl6a+Bu6CgjOy+8y0r9NEDs KLKFYFag5/eX31iR42//yA2MaRMVhvWqGfIb2MGc3i4ywR/jvoVBuO2NVmW6UlkljeqO 9P9/JhwwgtK4HD+JxWMEw4/5LKorYOLBwL9yVtxIDTh5JOjOPjZEaIoSBiRTRfE79d4s 3RVHx3wwGkyO++3gzPmVKgnrTMGILVyiFRxHnLl9Y/hUAr/HxXVhmY2qMEbgiU2W+P6I 92xko7BKbmPtr61eas7xI2y/qKp+fjXo00BRvxulMa/OkIhkATxmnnBqOVV+2u55bUCA 8OUw== X-Gm-Message-State: AOAM532aqhpYc7YEhscnbewn2C36Nq2jhLFLtyqy9yXxZJRebrXiab/m whRaOlA7cduBKwz0b77efTZ+cWE/Q/uUzHXAg8Wb92Hxgma8n5SrhBDhZMjgyAZXQdYKl8t8l5P 0wRM4vZTzNAE= X-Received: by 2002:a05:6000:1818:: with SMTP id m24mr19061606wrh.49.1627930056141; Mon, 02 Aug 2021 11:47:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyGLzls7DU16mDoxCL8Z/qw6AL3eM1mcV6oWIwd0406N+uBq7aMeNLjgAj9sclyhtqxEWTXtw== X-Received: by 2002:a05:6000:1818:: with SMTP id m24mr19061570wrh.49.1627930055907; Mon, 02 Aug 2021 11:47:35 -0700 (PDT) Received: from [192.168.3.132] (p5b0c60af.dip0.t-ipconnect.de. [91.12.96.175]) by smtp.gmail.com with ESMTPSA id z5sm164744wmp.26.2021.08.02.11.47.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Aug 2021 11:47:35 -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> <023d2435-8cc7-dc44-6258-4135136ddfba@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP Message-ID: <470865dc-64dc-713e-c8df-99a9067a19ba@redhat.com> Date: Mon, 2 Aug 2021 20:47:33 +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: rspam04 X-Rspamd-Queue-Id: 3464DF0017E3 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dQk3PxT2; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: czryei36pcxfkygfh36apmqyomgifqy5 X-HE-Tag: 1627930059-995091 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 02.08.21 12:19, Joerg Roedel wrote: > 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 chang= ing >> memory layouts. >=20 > 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, bu= t > I don't see this as a show stopper. Devil's in the details when you want to hotplug later; for example,=20 before parsing SRAT, we have no clue how much memory we might have at=20 one point at runtime later. And you'd have to prepare for that by=20 allocating the bitmap accordingly. And as I said, it's not a sparse data=20 structure, so you will at least waste some memory. >> I'm wondering, why exactly would a kdump kernel (not touching memory o= f 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 tha= t >> information when actually dumping memory of the old kernel, but it wou= ld >> have access to the memmap of the old kernel to obtain that information= . >=20 > The kdump kernel needs the bitmap to detect when the Hypervisor is doin= g > something malicious, well, at least on its own memory. The kdump kernel > has full access to the previous kernels memory and could also be tricke= d > by the Hypervisor to reveal secrets. That's an interesting thought. But this raises many questions, how and=20 what to dump in context of encrypted VMs at all. I'd love to see some=20 writeup of what we actually want to dump, with which tools, and to which=20 (encrypted?) locations. The kdump kernel has access to the memmap of the old kernel. The memmap=20 of the old kernel would contain information regarding encrypted pages.=20 The kdump kernel and the tools (makedumpfile) running in the VM cannot=20 be tampered with by the hypervisor. The memmap of the old kernel cannot=20 be tampered with, as it resides on encrypted memory. Are my assumptions=20 correct? I'd be interested how a hypervisor could trigger revealing secrets. >=20 >> Mirroring is a good point. But I'd suggest using the bitmap only durin= g >> 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 desi= gn. We >> can always try expressing the state of validated memory in the e820 ma= p we >> present to the kexec kernel. >=20 > 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 dow= n > the APs, but for kdump it would be too fragile to do such extensive > stuff before jumping the the kdump kernel. Right, I don't really see a blocker for kexec, just needs some proper=20 creation/update of the e820 map. For kdump, I am not sure if we really=20 need it, but most probably if we would have a complete picture of kdump=20 for encrypted VMs it would get much clearer what we actually have to=20 care about. --=20 Thanks, David / dhildenb