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 20320C433F5 for ; Fri, 29 Apr 2022 19:46:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 808616B0071; Fri, 29 Apr 2022 15:46:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B74B6B0072; Fri, 29 Apr 2022 15:46:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A5076B0073; Fri, 29 Apr 2022 15:46:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 5C6A16B0071 for ; Fri, 29 Apr 2022 15:46:53 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 298B6770 for ; Fri, 29 Apr 2022 19:46:53 +0000 (UTC) X-FDA: 79410949506.29.EE72724 Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) by imf25.hostedemail.com (Postfix) with ESMTP id 34CEAA0078 for ; Fri, 29 Apr 2022 19:46:42 +0000 (UTC) Received: by mail-vs1-f44.google.com with SMTP id y74so8535385vsy.7 for ; Fri, 29 Apr 2022 12:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zvNglwrmd5vF7mMDmsRljPMUFF4MTul226NsBSC+/Bs=; b=IMfw90qU+MP8ObHiqAkD+cZ02qfHL2+eKjZavGk6KY+zmNiq4CP/rtLvahiiehfNph 4IndOpAijat2WFSczZXj5K3Ua72tCmZ7Pgzv1CzekceQCxdnA9oMek+FpoFsKc7fQzis vXQNFeEyQ6JT+kaCDBxs4Yj5hOyNOxJrtWzInmL/Ovnd3fq/EzHyDuJidGhTpLSdqeIa lN+EFiAlc+WombBjmRStG159HhkteyOaf1JkXX0BKb65GNGJEqUHtUzCdynxHMePS2ow SBYwz+EyM2ew2mggUnMocLUBtePjjdUS0b5chDADtGP8n/Vcn1u6Urq+7AxD7s3aSFHR XA2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zvNglwrmd5vF7mMDmsRljPMUFF4MTul226NsBSC+/Bs=; b=LHtmp1cgizjjYE5Vbz7z1+1YWW6nGjnapXL+wBvJPnAinLJvKql4ptrtfDjS3vd7hW Zttx7i9GuTi75KU0IxluBa0FDfvfrP/coB6sxUmoZJRL4FHkSFjSrPhWENvk250QHDOz ntAfEitYoJA++palrPdb3xvo2fesKgt6gCKwlCcpoIA0Flq7RimaFpwwJiTfQy9qGb5L I9admIZt+pziEk8SGyZfJdFZhBiXGOT3eqh5PTEB0/4jbz5nXR1eLIjNXfmbpZ+QxXP4 H4BBTpQ3QylcFQz4e2h6C+mUgn0WwMbhCMRPd8Q6vvD31YYyNLlHR++Al2V17Zilf96I HtUw== X-Gm-Message-State: AOAM533tqpf1xnycBO6kQatmNIS2dz+SUtQ5b/SHi3S2//lfvt09aqVM l+gfYlgNQKuNAVWpA5RzpxFFIRAnFAa/LehXJjQgbQ== X-Google-Smtp-Source: ABdhPJzTj15MZ5SKv3m5spA5qCxG01bZu7l1VgNJuHMyCumC8smdFB21vEjXdz0rvtqv4SSF5iAjaNSjyFORJ/o6Cqs= X-Received: by 2002:a67:c58c:0:b0:32c:fb57:2f76 with SMTP id h12-20020a67c58c000000b0032cfb572f76mr399934vsk.53.1651261611793; Fri, 29 Apr 2022 12:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20220428161551.722296-1-erdemaktas@google.com> <6f99684f-172c-ccf2-0be3-9aca85451079@intel.com> In-Reply-To: <6f99684f-172c-ccf2-0be3-9aca85451079@intel.com> From: Jue Wang Date: Fri, 29 Apr 2022 12:46:40 -0700 Message-ID: Subject: Re: [RFC] Expose a memory poison detector ioctl to user space. To: Dave Hansen Cc: Erdem Aktas , almasrymina@google.com, dave.hansen@linux.intel.com, gthelen@google.com, jiaqiyan@google.com, linux-mm@kvack.org, naoya.horiguchi@nec.com, seanjc@google.com, tony.luck@intel.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 34CEAA0078 X-Stat-Signature: m5chzfrottk9tktm4web9meia6xug9xo X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=IMfw90qU; spf=pass (imf25.hostedemail.com: domain of juew@google.com designates 209.85.217.44 as permitted sender) smtp.mailfrom=juew@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1651261602-949059 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000067, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Thanks Erdem and Dave, as a summary: 1. Reading via direct mapping from guest private memory should not generate #MC and it should result in expected memory error poisoning behavior (to be confirmed). 2. Reading via direct mapping from SEV-SNP guest private memory does not generate #MC or #PF. Per seanjc@google.com: TDX doesn't support #MC exception injection, but IRQ "injection" via posted interrupts is supported. Accesses to machine check MSRs will #VE, i.e. can be emulated by KVM, so CMCI should work fine for TDX guests. Proactively scanning for memory error should benefit TDX guests preventing potential host shutdowns. It seems the current proposed design can cover TDX & SEV-SNP if the direct mapping to guest private memory is preserved? Thanks, -Jue On Thu, Apr 28, 2022 at 9:34 AM Dave Hansen wrote: > > On 4/28/22 09:15, Erdem Aktas wrote: > >> On 4/26/22 12:23, Jue Wang wrote: > >>> On Tue, Apr 26, 2022 at 11:18 AM Dave Hansen wrote: > >> 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. > > > > Actually, afaiu, the host can read tdx private memory. This should NOT generate > > #MC due to integrity/TD ownership but return a fixed value of "0"s. I do not > > know if this will also trigger #MCs due to memory errors. > > I think you're right, at least in the normal case where the access is > performed with the TME KeyID. "An introductory overview of the Intel > TDX technology"[1] says: > > > The TD-bit associated with the line in memory seeks to > > detect software or devices attempting to read memory > > encrypted with private KeyID, using a shared KeyID, to reveal > > the ciphertext. On such accesses, the MKTME returns a fixed > > pattern to prevent ciphertext analysis. > > I guess, in practice, the read would need to go all the way out to the > memory controller to get the TD-bit. But, it's definitely not > well-defined in the spec. > > 1. > https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.html