[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <051fd468-11e6-308b-66c8-4de16ff80deb@intel.com>
Date: Wed, 15 Jun 2022 08:27:52 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
luto@...nel.org, peterz@...radead.org
Cc: ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
hpa@...or.com, linux-kernel@...r.kernel.org,
sathyanarayanan.kuppuswamy@...ux.intel.com, seanjc@...gle.com,
thomas.lendacky@....com, x86@...nel.org
Subject: Re: [PATCHv4 3/3] x86/tdx: Handle load_unaligned_zeropad() page-cross
to a shared page
On 6/14/22 05:01, Kirill A. Shutemov wrote:
> load_unaligned_zeropad() can lead to unwanted loads across page boundaries.
> The unwanted loads are typically harmless. But, they might be made to
> totally unrelated or even unmapped memory. load_unaligned_zeropad()
> relies on exception fixup (#PF, #GP and now #VE) to recover from these
> unwanted loads.
>
> In TDX guests, the second page can be shared page and VMM may configure
> it to trigger #VE.
>
> Kernel assumes that #VE on a shared page is MMIO access and tries to
> decode instruction to handle it. In case of load_unaligned_zeropad() it
> may result in confusion as it is not MMIO access.
>
> Fix it by detecting split page MMIO accesses and fail them.
> load_unaligned_zeropad() will recover using exception fixups.
>
> The issue was discovered by analysis. It was not triggered during the
> testing.
I thought this whole exercise was kicked off by hitting this in testing.
Am I remembering this wrong?
> https://lore.kernel.org/all/20220517153444.11195-10-kirill.shutemov@linux.intel.com/
Says:
> This is an actual, real-world problem which was discovered during TDX
> testing.
Or were you considering this a different problem somehow?
Powered by blists - more mailing lists