linux-kernel - Re: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the RMP fault for user address

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: <a249b101-87d1-2e66-d7d6-af737c045cc3@intel.com>
Date:   Mon, 12 Jul 2021 09:00:56 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Brijesh Singh <brijesh.singh@....com>, 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
Cc:     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>,
        Sean Christopherson <seanjc@...gle.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>,
        Vlastimil Babka <vbabka@...e.cz>, tony.luck@...el.com,
        npmccallum@...hat.com, brijesh.ksingh@...il.com
Subject: Re: [PATCH Part2 RFC v4 10/40] x86/fault: Add support to handle the
 RMP fault for user address

On 7/12/21 8:43 AM, Brijesh Singh wrote:
>>> +    /*
>>> +     * The backing page level is higher than the RMP page level,
>>> request
>>> +     * to split the page.
>>> +     */
>>> +    if (level > rmp_level)
>>> +        return RMP_FAULT_PAGE_SPLIT;
>>
>> This can theoretically trigger on a hugetlbfs page.  Right?
> 
> Yes, theoretically.
> 
> In the current implementation, the VMM is enlightened to not use the
> hugetlbfs for backing page when creating the SEV-SNP guests.

"The VMM"?

We try to write kernel code so that it "works" and doesn't do unexpected
things with whatever userspace might throw at it.  This seems to be
written with an assumption that no VMM will ever use hugetlbfs with SEV-SNP.

That worries me.  Not only because someone is sure to try it, but it's
the kind of assumption that an attacker or a fuzzer might try.

Could you please test this kernel code in practice with hugetblfs?

>> I also suspect you can just set VM_FAULT_SIGBUS and let the do_sigbus()
>> call later on in the function do its work.
>>>   +static int handle_split_page_fault(struct vm_fault *vmf)
>>> +{
>>> +    if (!IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT))
>>> +        return VM_FAULT_SIGBUS;
>>> +
>>> +    __split_huge_pmd(vmf->vma, vmf->pmd, vmf->address, false, NULL);
>>> +    return 0;
>>> +}
>>
>> What will this do when you hand it a hugetlbfs page?
> 
> VMM is updated to not use the hugetlbfs when creating SEV-SNP guests.
> So, we should not run into it.

Please fix this code to handle hugetlbfs along with any other non-THP
source of level>0 mappings.  DAX comes to mind.  "Handle" can mean
rejecting these.  You don't have to find some way to split them and make
the VM work, just fail safely, ideally as early as possible.

To me, this is a fundamental requirement before this code can be accepted.

How many more parts of this series are predicated on the behavior of the
VMM like this?