linux-kernel - Re: [PATCH Part2 RFC v4 07/40] x86/sev: Split the physmap when adding the page in RMP table

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: <b6793038-c24b-a65b-1ca4-ed581b254ff4@suse.cz>
Date:   Fri, 30 Jul 2021 13:31:02 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Brijesh Singh <brijesh.singh@....com>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        linux-crypto@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Borislav Petkov <bp@...en8.de>,
        Michael Roth <michael.roth@....com>, tony.luck@...el.com,
        npmccallum@...hat.com, brijesh.ksingh@...il.com
Subject: Re: [PATCH Part2 RFC v4 07/40] x86/sev: Split the physmap when adding
 the page in RMP table

On 7/15/21 9:38 PM, Brijesh Singh wrote:
> 
> 
> On 7/15/21 1:39 PM, Sean Christopherson wrote:
>> On Thu, Jul 15, 2021, Brijesh Singh wrote:
>>> The memfd_secrets uses the set_direct_map_{invalid,default}_noflush() and it
>>> is designed to remove/add the present bit in the direct map. We can't use
>>> them, because in our case the page may get accessed by the KVM (e.g
>>> kvm_guest_write, kvm_guest_map etc).
>>
>> But KVM should never access a guest private page, i.e. the direct map should
>> always be restored to PRESENT before KVM attempts to access the page.
>>
> 
> Yes, KVM should *never* access the guest private pages. So, we could potentially
> enhance the RMPUPDATE() to check for the assigned and act accordingly.

I think I'm not the first one suggesting it, but IMHO the best solution would be
to leave direct map alone (except maybe in some debugging/development mode where
you could do the unmapping to catch unexpected host accesses), and once there's
a situation with host accessing a shared page of the guest, it would temporarily
kmap() it outside of the direct map. Shouldn't these situations be rare enough,
and already recognizable due to the need to set up the page sharing in the first
place, that this approach would be feasible?

> Are you thinking something along the line of this:
> 
> int rmpupdate(struct page *page, struct rmpupdate *val)
> {
>     ...
>     
>     /*
>      * If page is getting assigned in the RMP entry then unmap
>      * it from the direct map before its added in the RMP table.
>      */
>     if (val.assigned)
>         set_direct_map_invalid_noflush(page_to_virt(page), 1);
> 
>     ...
> 
>     /*
>      * If the page is getting unassigned then restore the mapping
>      * in the direct map after its removed from the RMP table.
>      */
>     if (!val.assigned)
>         set_direct_map_default_noflush(page_to_virt(page), 1);
>     
>     ...
> }
> 
> thanks