linux-kernel - Re: [PATCHv4 10/14] x86/tdx: Convert shared memory back to private on kexec

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: <33d90a6374cd0bab358725a0ba1b52fbe99f5170.camel@intel.com>
Date:   Wed, 6 Dec 2023 18:32:11 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
CC:     "kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
        "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
        "Huang, Kai" <kai.huang@...el.com>,
        "ashish.kalra@....com" <ashish.kalra@....com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "Hunter, Adrian" <adrian.hunter@...el.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "bhe@...hat.com" <bhe@...hat.com>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCHv4 10/14] x86/tdx: Convert shared memory back to private on
 kexec

On Wed, 2023-12-06 at 18:07 +0300, kirill.shutemov@...ux.intel.com
wrote:
>  I can't think of any non-ridiculous way to handle this case. Maybe
> we
> > need VMM help.
> 
> Do you see a specific way how VMM can help here?

I didn't have a specific idea. I was just thinking that the problem is
that guest doesn't know the exact private/shared state of the GFNs
because of the potentially interrupted conversion processes. But the
VMM does have this information. 

What about something like: The VMM could expose something like MapGPA
that searches for a shared GPA and return it. So you ask it to convert
the next shared GPA it can find to private and it searches (in the
host) the xarray stuff to find a GPA that is shared. Then in the guest,
it has a shared GPA and check the direct map PTE to reset, and accept.

The guest could call the new MapGPA-like hypercall in a loop until all
GPAs are reset.

> > I'd still wonder about if anything might try to
> > access a shared page triggered by the console output.
> 
> set_memory_np() would make it obvious if it ever happens.

I think this is a worthwhile improvement over the existing complete
lack of support, but it's not race free. With the barrier comments, and
given the lack of good alternatives:

Reviewed-by: Rick Edgecombe <rick.p.edgecombe@...el.com>