linux-kernel - Re: [PATCH 2/2] KVM: TDX: Do not clear poisoned pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <91df7051-2405-4609-9e86-2bbc02829644@intel.com>
Date: Wed, 25 Jun 2025 15:38:19 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Kai" <kai.huang@...el.com>,
 "Hunter, Adrian" <adrian.hunter@...el.com>,
 "Annapurve, Vishal" <vannapurve@...gle.com>
Cc: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
 "Li, Xiaoyao" <xiaoyao.li@...el.com>, "Luck, Tony" <tony.luck@...el.com>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "tony.lindgren@...ux.intel.com" <tony.lindgren@...ux.intel.com>,
 "Zhao, Yan Y" <yan.y.zhao@...el.com>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "seanjc@...gle.com" <seanjc@...gle.com>,
 "Chatre, Reinette" <reinette.chatre@...el.com>,
 "pbonzini@...hat.com" <pbonzini@...hat.com>,
 "mingo@...hat.com" <mingo@...hat.com>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
 "binbin.wu@...ux.intel.com" <binbin.wu@...ux.intel.com>,
 "Yamahata, Isaku" <isaku.yamahata@...el.com>,
 "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
 "hpa@...or.com" <hpa@...or.com>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, "bp@...en8.de"
 <bp@...en8.de>, "Gao, Chao" <chao.gao@...el.com>,
 "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH 2/2] KVM: TDX: Do not clear poisoned pages

On 6/25/25 15:32, Huang, Kai wrote:
>> 2. page may have had an integrity violation or a hardware error
>> (we can't tell which), and PageHWPoison(page) is true
> Right.  I think the point of avoiding MOVDIR64B to such page is we cannot
> tell whether it is a hardware error or not.  If it is a hardware error,
> touching it using MOVDIR64B may cause additional #MC which will panic kernel
> since now the #MC happens in the kernel context.

First and foremost, does the code path in question in this case touch
userspace pages? Or pages that are only "kernel context" in the first place.

Second, if we can't tell the difference between integrity violation or a
hardware error and this code needs to clear "integrity violation" poison
then won't this change just fundamentally break the erratum workaround
in the first place?!?!