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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8B59AC433EF for ; Tue, 26 Apr 2022 19:36:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16B006B0073; Tue, 26 Apr 2022 15:36:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F4226B0074; Tue, 26 Apr 2022 15:36:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB0246B0075; Tue, 26 Apr 2022 15:36:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id D678B6B0073 for ; Tue, 26 Apr 2022 15:36:22 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B5360261D6 for ; Tue, 26 Apr 2022 19:36:22 +0000 (UTC) X-FDA: 79400036604.31.E2D899C Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf16.hostedemail.com (Postfix) with ESMTP id 61ED9180058 for ; Tue, 26 Apr 2022 19:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651001781; x=1682537781; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Aj3TxheRqLhggQm5gOSVt18AwG7D/qCjt1qqdeBDeK8=; b=MEzX3QRJ456JYr2gx5ig00Y/Buq63dEOunDNA7oFUgo1Nm4KC6TDu0K3 NpAMmk4Vec6nzb5QP4/semAaPMrid6YkEEt5aavehnOvKbaXMbQFwlp19 yfhPaKiqoqaVQDiQrz1Qq0zacxoMa3pECO1loPGpICd8xy+wYXUKAygDx 7ryzRnNpuX+cbLmoSTstL+XX4pelDy5n4CjcKSsLn9vBAY4GIDB3lv42Q a1JRcUAXIFPMBhFV1D7ufScfl4Oefq1dBpEIA/ip0qdfbbKunigV4NWDS k6qKLQICNqBBfiMUJuAeZ+KEe2yjpcyYEsDiBMfDpJNN6tGXLVsa9H+EU w==; X-IronPort-AV: E=McAfee;i="6400,9594,10329"; a="326189996" X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="326189996" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 12:36:20 -0700 X-IronPort-AV: E=Sophos;i="5.90,291,1643702400"; d="scan'208";a="580116323" Received: from dsocek-mobl2.amr.corp.intel.com (HELO [10.212.69.119]) ([10.212.69.119]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Apr 2022 12:36:19 -0700 Message-ID: Date: Tue, 26 Apr 2022 12:39:05 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. Content-Language: en-US To: Jue Wang Cc: Naoya Horiguchi , Tony Luck , Dave Hansen , Jiaqi Yan , Greg Thelen , Mina Almasry , linux-mm@kvack.org, Sean Christopherson References: <20220425163451.3818838-1-juew@google.com> <5a7f00e3-311d-b5ca-4249-7f50f8712559@intel.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MEzX3QRJ; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf16.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=dave.hansen@intel.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 61ED9180058 X-Rspam-User: X-Stat-Signature: 1otjx8dyskfnpfma96fjcrefg1uoehcc X-HE-Tag: 1651001778-48016 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 4/26/22 12:23, Jue Wang wrote: > On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen wrote: >> What if you're in a normal (non-TDX) guest and some of the physical >> address space has been ballooned away? > > Accessing to memory that gets ballooned away will cause extra EPT > violations and have the memory faulted in on the host side, which is > transparent to the guest. Yeah, but it completely subverts the whole purpose of ballooning. In other words, this is for all intents and purposes also mutually exclusive with ballooning. >> What does the kernel do when userspace asks it to poke a non-"System >> RAM" address? > > I expect the kernel should reject the request with -EINVAL. Right. Only the kernel has the knowledge of what can actually _be_ scanned. So, why even bother exposing physical addresses to userspace? Why is exposing the actual physical address any better than exposing a cookie? > Just curious, what could be recommendations from Intel's perspective > to make proactively poison detection work on TDX / SEV-SNP? I shouldn't speak for Intel as a whole, but I'll give you my personal perspective. Right now, hosts can't scan TDX private memory, period. If you wanted to do scanning, the guest has to do it or you have to kill the guest and make the memory non-private. Going forward, guest memory scanning could be accomplished by allowing the VMM to migrate guest pages. Let's say you want to scan page "A", you could move A->B and B->A. That would certainly touch the page. This would need to be implemented in the TDX module. Or, the TDX module could have a special call to just touch the page. It would probably also need more work in the TDX module to be able to handle machine checks. I don't think the handling in there is very robust today. It could also be implemented with some new VMM-side ISA which promises to touch the physical memory, but doesn't return any data, ignores the "TD bit" and doesn't do any integrity checking.