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 B5D95EB64D7 for ; Tue, 20 Jun 2023 15:40:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BEC08D0002; Tue, 20 Jun 2023 11:40:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16F018D0001; Tue, 20 Jun 2023 11:40:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 068B68D0002; Tue, 20 Jun 2023 11:40:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id EA0F78D0001 for ; Tue, 20 Jun 2023 11:40:07 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id ABF4E1A1246 for ; Tue, 20 Jun 2023 15:40:07 +0000 (UTC) X-FDA: 80923537254.21.064DB58 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf14.hostedemail.com (Postfix) with ESMTP id 12349100013 for ; Tue, 20 Jun 2023 15:40:04 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lfis38vY; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687275605; h=from:from:sender: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:dkim-signature; bh=QUsgQzdHUx0u2IvJQIu4dTdtqd9JFFXVBRTtdI1yI0Y=; b=oymp5U2a+mY9S9FxsgMLN6qeZ6AxUg84i07TYs4BHIjns3LrHcNQiewZCINWB/dxZEqhXv C9pNl0TWfDIgBNlcH0Hwb6DwQd+WfVGxktna3iIsfkT5fL/3a7hy+tN7EmvJG9vrgKyFmO iDkxVDHz1YZrV9i8+xNr8zl6K1ZcP8I= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687275605; a=rsa-sha256; cv=none; b=afwDyJ66GpATVl2Rx6dlUof/IXUrfSvSzt/wl0OiebzzepgLxpPZ8pRxJY8eU4F+qYcm3c 0b8SJ1M9r7XucJ1xCWbsNbJ6AuadSF70sJd7NIi3aZ9tmOUffYxM5FycKl8F3Hr1SiSLsT 18AU+E/VRGqD7RqEV0jwLf7A+FwZsHw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=lfis38vY; spf=pass (imf14.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687275605; x=1718811605; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=wxOtILeVt+OcJwdm6KRHBAGZ5isFatuQAs5FDwV9Rzk=; b=lfis38vYoAnqHMrePpOjrbyOJqiSJ7uU3itpTJVxhrW8HZkFDomEUhNI borMvjfoLwa8yp3UgtFw8YFY4/7WFDsh0siz0eMYxL+oX10lkRh438Hhz NsC/EiLpQlGBlS20oCkjUUdLMO7OOcWHjrgWIJSO0ZAAYv28BjYwsYicR sFEmXdhyzxxVF610WytI7QQO340FeamwdE1wshp6fqKZlUdjpQxeILsWl 1UcdZJDM41JOgV2D1h50qiEO9d46lkJxZLQVNYLAe1cjh5JSjnOQIYbVS aVBEU9WaQ1mW+HCm7pyf+A0OZKSpvD4gTf5REgfi5yb2iTAHeR7gzml7n A==; X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="359902862" X-IronPort-AV: E=Sophos;i="6.00,257,1681196400"; d="scan'208";a="359902862" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2023 08:39:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10747"; a="827045577" X-IronPort-AV: E=Sophos;i="6.00,257,1681196400"; d="scan'208";a="827045577" Received: from rashmigh-mobl.amr.corp.intel.com (HELO [10.255.228.28]) ([10.255.228.28]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jun 2023 08:39:50 -0700 Message-ID: Date: Tue, 20 Jun 2023 08:39:49 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v11 04/20] x86/cpu: Detect TDX partial write machine check erratum Content-Language: en-US To: David Hildenbrand , Kai Huang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: linux-mm@kvack.org, kirill.shutemov@linux.intel.com, tony.luck@intel.com, peterz@infradead.org, tglx@linutronix.de, seanjc@google.com, pbonzini@redhat.com, dan.j.williams@intel.com, rafael.j.wysocki@intel.com, ying.huang@intel.com, reinette.chatre@intel.com, len.brown@intel.com, ak@linux.intel.com, isaku.yamahata@intel.com, chao.gao@intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com, sagis@google.com, imammedo@redhat.com References: <86f2a8814240f4bbe850f6a09fc9d0b934979d1b.1685887183.git.kai.huang@intel.com> <723dd9da-ebd5-edb0-e9e5-2d8c14aaffe2@redhat.com> From: Dave Hansen In-Reply-To: <723dd9da-ebd5-edb0-e9e5-2d8c14aaffe2@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: q3g7kbk8a9q4gzsanush4unc4hyz7wqt X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 12349100013 X-Rspam-User: X-HE-Tag: 1687275604-670714 X-HE-Meta: U2FsdGVkX19ttu9HM91OHCezWl+T5hieMXBgI45JYaJY0dFaNytBnB9r01pfgVqmp63fYmE2q1S9/fxvzAgUPGCxOwun170YK8n1579EsqLxjqW09q8obAlJuH4GCtx5qkdYPW5j4KZLCcDYQy5ru8MPCimVTEw8uehBXdcm9jXpjd0838i1gkbnBuCefnYcNicWai/Y8kZD5bisIWkWi8+rYefLRf8q/XOgTFQKzSpIrNhFfzgSG4EEzZKF5HZHL2CRfHvBmwE6u0eGIPJ7CF836Ms2aDpcoSg8sjQA01uuFeGt3c2UfvzzUE33dZGZkxDwb32PCWLkwLq2DsWvDzcbLdf0H++eghHbjewNcdI95/pyP3BW3sUAmVToSJXUFURBkB/DuaVvtpW1MaQ9UVdUvuIMxG8inpRWL/Gaqh9qvPX6rEekGKJkQZyxxXdIJSVJR+qft92QyuYUzaUffWqcYshYPRRKahOYpBWP4uTG8gw0+WHVdSaYXpBMvVzUyEUK0DqJ9h76+VtLwc99W7+AEGeFy1RWdO5GGGly+Tl0X2ByBtU2bSF6ebbdxsldU8YbnS4PpAaxQ5oXLC9VoFT/XSEnZJmTS24vhlcoLCGLafMESbWGSioswCkERxqX8D8pc3rdizljLy3L3ZICdGqRCT6wnOQLrcfSmZPdlm9tYrSZ9INi8BRkCpPYiThByPADv8K03MRhZIdRTFt65AivGfQYrDJlljkS6U/9/zQugAdZ0rtHRL2iwDj5srHUz6JDWaV2AWN1lblJ8F9Td+HiOpF2xHMKNAsf+B9gSPG6Ocnn/GwiNhglxeBPTx9udZiv98Lsrnv/iRxLq/msDlYMOdDuORyGYLkrlJrTLKUW3n50g0krob8p8QOlK7wTiQEJ//pSIn5LewvxLcOTkitC9WxJTZIx+jEBfQyFWJXJ8iPE2miRp1d+vxsg+WxLXEBFd3N67x+zZhGhY7T zgVsllwH Id4WSNcyOvneuUX3NndP68f1gMMxd03DN/VqOm4/6KB3T9hPX3z/GpZrmU1YohAPDNLVVU0TtC56WrRVUZnOevN/4MOreGTeK//dJXSX3bZn+JaWEPMy4xtGtOg+yP4iaTECh/qn0p+ZnGLHJXmSkTGiBQVQb8oCsE0jWOvTKj04PJAc= 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 6/19/23 05:21, David Hildenbrand wrote: > So, ordinary writes to TD private memory are not a problem? I thought > one motivation for the unmapped-guest-memory discussion was to prevent > host (userspace) writes to such memory because it would trigger a MC and > eventually crash the host. Those are two different problems. Problem #1 (this patch): The host encounters poison when going about its normal business accessing normal memory. This happens when something in the host accidentally clobbers some TDX memory and *then* reads it. Only occurs with partial writes. Problem #2 (addressed with unmapping): Host *userspace* intentionally and maliciously clobbers some TDX memory and then the TDX module or a TDX guest can't run because the memory integrity checks (checksum or TD bit) fail. This can also take the system down because #MC's are nasty. Host userspace unmapping doesn't prevent problem #1 because it's the kernel who screwed up with the _kernel_ mapping.