linux-kernel - RE: [PATCHv2 2/3] x86/tdx: Fix race between set_memory_encrypted() and load_unaligned

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: <BYAPR21MB1688EF2A57E90FCE02B82F84D748A@BYAPR21MB1688.namprd21.prod.outlook.com>
Date:   Wed, 31 May 2023 20:00:23 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Sathyanarayanan Kuppuswamy 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Kirill A. Shutemov" <kirill@...temov.name>
CC:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, Dexuan Cui <decui@...rosoft.com>,
        "rick.p.edgecombe@...el.com" <rick.p.edgecombe@...el.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: RE: [PATCHv2 2/3] x86/tdx: Fix race between set_memory_encrypted()
 and load_unaligned_zeropad()

From: Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...ux.intel.com>
Sent: Tuesday, May 30, 2023 6:22 AM
> 
> Hi,
> 
> On 5/30/23 5:57 AM, Tom Lendacky wrote:
> > On 5/29/23 19:57, Kirill A. Shutemov wrote:
> >> On Fri, May 26, 2023 at 03:10:56PM -0700, Sathyanarayanan Kuppuswamy wrote:
> >>>
> >>>
> >>> On 5/26/23 5:02 AM, Kirill A. Shutemov wrote:
> >>>> Touching privately mapped GPA that is not properly converted to private
> >>>> with MapGPA and accepted leads to unrecoverable exit to VMM.
> >>>>
> >>>> load_unaligned_zeropad() can touch memory that is not owned by the
> >>>> caller, but just happened to next after the owned memory.
> >>>
> >>> /s/to/to be ?
> >>
> >> Yep, my bad.
> >>
> >>>> This load_unaligned_zeropad() behaviour makes it important when kernel
> >>>> asks VMM to convert a GPA from shared to private or back. Kernel must
> >>>> never have a page mapped into direct mapping (and aliases) as private
> >>>> when the GPA is already converted to shared or when GPA is not yet
> >>>> converted to private.
> >>>
> >>> I am wondering whether this issue exist in the AMD code?
> >>>
> >>> IMO, you can add some info on the window in set_memory_encrypted()
> >>> where this race exists.
> >>
> >> I don't think AMD affected by load_unaligned_zeropad() the same way as
> >> Intel does. But I'm not sure.
> >>
> >> Tom, do you have any comments?
> >
> > Right, shouldn't be an issue for SNP.
> 
> Thanks for confirming.
> 

Tom -- For my education, could you elaborate on why this problem can't
occur in an SEV-SNP guest?  There's still a window where the direct map
PTE and the RMP as maintained by the hypervisor are out-of-sync.  If
load_unaligned_zeropad() does a read using the direct map PTE during
this out-of-sync window, isn't that going to trap to the hypervisor?  How
is the scenario is handled from there to provide the zeros to
load_unaligned_zeropad()?  I need to make sure Hyper-V is doing whatever
is needed. :-)  

Thanks,

Michael