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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 045B4C07E9B for ; Tue, 20 Jul 2021 23:10:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D34A61029 for ; Tue, 20 Jul 2021 23:10:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D34A61029 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EA28E6B0011; Tue, 20 Jul 2021 19:10:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E52CB6B0036; Tue, 20 Jul 2021 19:10:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF4506B006C; Tue, 20 Jul 2021 19:10:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id A79696B0011 for ; Tue, 20 Jul 2021 19:10:11 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 30D888248047 for ; Tue, 20 Jul 2021 23:10:10 +0000 (UTC) X-FDA: 78384511380.29.31F42FF Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) by imf09.hostedemail.com (Postfix) with ESMTP id E391A3001D8C for ; Tue, 20 Jul 2021 23:10:09 +0000 (UTC) Received: by mail-pg1-f180.google.com with SMTP id 70so163683pgh.2 for ; Tue, 20 Jul 2021 16:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8GS05+M5HxIVJGD8swK1udLTBOXRLN/mWtXb22swtSk=; b=fo7zBSNhZlxBGzkz3iTxRF04ETYxLay9z+B74c7Cg9MTGKARF6wNQDL6q+0N/KxSfl VLUxHuJ5MJN0JblQC1tyuMrE0i7tLBZmec860Nfc3faibAL9ODWdv+ALf0RFIFpA/S/b oWwJwl7NlZhlbe6lDXeTNbXcoYJ0gz7zkzIjgvYilStAlGtFsfG6+ilddzZCoVbvMinJ 4UoIGGW/+WEgbQlYRMMujTb9gf9UQBmbggDlAOPNeCNkqTA/0AjDbP6zECVsRGVfRl76 spBal5q+vUjpQpkSSBV+BnecwkN8oJJaVlfvRlMljXTmh0LdiRQYOSaIcfXrZJzLQs6n ipWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8GS05+M5HxIVJGD8swK1udLTBOXRLN/mWtXb22swtSk=; b=Z5wmAebsMZulI1TCT5E1F9ei9/GbvLlUKdkvfVg1ig3ZeO6TVyCaC+OoQygtQrxWwh EWs3O2bDGbau7uX2CGF1V9LsXlPrF97vkcxE2Yus5WtdbQjpTBliT1rW7pDvTP7mHHtH FqgDhgLhZJuVyyY3Or3TML2R2gO0DSj82KcR7B3UmtYvv32AUH9D/IthixAL/CK+Onh9 BjTU4oND4EUtRw+uyB5qQ5Djs+apzRpYv5pSqY9327Rl4e6i1cXob0IKeuA0mAtcFSfp 97CB3ZhoDb6YgbQ2+CkK9KeB/Sb7VTPo0xfaMnGJ2ZOLero/AqeJPeOgbERleZk1EDQ3 VZlw== X-Gm-Message-State: AOAM533QM58gvuaPLZyoEwyQgDwf0QwVomIT34vOMrv/XVEc6BjbvdQo 8EfrEfjEx25l+vE9AUEj9lgscflEtpb2ws8VVnt8Tg== X-Google-Smtp-Source: ABdhPJzRYfGoJ4OMK4+YDvysh2ep9yENDjPmZ3bVp/z4TLjM/bNNnaSTdqVgm0u/oD9Rksv6bkICleek0amw+M3BuAs= X-Received: by 2002:a05:6a00:8c4:b029:2b4:8334:ed4d with SMTP id s4-20020a056a0008c4b02902b48334ed4dmr33013122pfu.36.1626822608693; Tue, 20 Jul 2021 16:10:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erdem Aktas Date: Tue, 20 Jul 2021 16:09:58 -0700 Message-ID: Subject: Re: Runtime Memory Validation in Intel-TDX and AMD-SNP To: Andi Kleen Cc: Andy Lutomirski , Joerg Roedel , David Rientjes , Borislav Petkov , Sean Christopherson , Andrew Morton , Vlastimil Babka , "Kirill A. Shutemov" , Brijesh Singh , Tom Lendacky , Jon Grimm , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , "Kaplan, David" , Varad Gautam , Dario Faggioli , x86 , linux-mm@kvack.org, linux-coco@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=fo7zBSNh; spf=pass (imf09.hostedemail.com: domain of erdemaktas@google.com designates 209.85.215.180 as permitted sender) smtp.mailfrom=erdemaktas@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: igj7atgd6zaanzsbjbsk1595mktr8rg6 X-Rspamd-Queue-Id: E391A3001D8C X-Rspamd-Server: rspam01 X-HE-Tag: 1626822609-70869 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 Mon, Jul 19, 2021 at 10:17 PM Andi Kleen wrote: > > First I suspect for crash it's not a real security problem if a > malicious hypervisor would inject zeroed pages. That means actual strong > checks against revalidation/reaccept are not needed. That still leaves > the issue of triggering an exception when the memory is not there. TDX > has an option to trigger a #VE in this case, but we will actually force > disable it to avoid #VE in the system call gap. But the standard crash > dump tools already know how to parse mem_map to distinguish different > types of pages. So they already would be able to do that. We just need > some kind of safety mechanism to prevent any crashes, but that should be > doable. Actually I'm not sure they're really needed because that's a > root operation. Just to make sure that I am not confused. We are talking about a scenario where no private/shared page mapping is transferred between normal kernel and crash kernel. It is very hard to identify a security issue without seeing an implementation but if the crash kernel does not revalidate the memory, it might use a memory which was not accepted before (for example a previously shared page) and then it needs to handle EPT-violation #VE to accept it and now the content is gone. - assuming that we want to dump all the pages. I might be missing something obvious here but I am not sure how to crash kernel dumps all the memory when #VE handler is disabled or without having some private/shared page mapping. Once you have that #VE handler to accept pages, then VMM can inject zeroed pages to any location unless the guest keeps track of what has been accepted before. > > >> Also in general i don't think it will really happen, at least > > initially. > > >> All the shared buffers we use are allocated and never freed. So such a > > >> problem could be deferred. > > > > Does it not depend on kernel configs? Currently, there is a valid > > control path in dma_alloc_coherent which might alloc and free shared > > pages. > > If the device filter is active it won't. > If I am not missing something, I do not see that the device filter checks for CONFIG_DMA_COHERENT_POOL and if it is not enabled, dma_alloc_coherent will allocate a regular memory, convert it to shared and convert it back to private when it is freed. -Erdem > > >> At the risk of asking a potentially silly question, would it be > > >> reasonable to treat non-validated memory as not-present for kernel > > >> purposes and hot-add it in a thread as it gets validated? > > > > My concern with this is, it assumes that all the present memory is > > private. UEFI might have some pages which are shared therefore also > > are present. > > > Hot add is nearly always a bad idea. > > > -Andi > > >