linux-kernel - Re: [PATCH v2 2/4] mm: x86: Invoke hypercall when page encryption status is changed

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <86701a5e-87b5-4e73-9b7a-557d8c855f89@www.fastmail.com>
Date:   Wed, 19 May 2021 16:29:37 -0700
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Borislav Petkov" <bp@...en8.de>,
        "Ashish Kalra" <Ashish.Kalra@....com>,
        "Sean Christopherson" <seanjc@...gle.com>
Cc:     "Paolo Bonzini" <pbonzini@...hat.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        "Joerg Roedel" <joro@...tes.org>, thomas.lendacky@....com,
        "the arch/x86 maintainers" <x86@...nel.org>,
        "kvm list" <kvm@...r.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        srutherford@...gle.com, venu.busireddy@...cle.com,
        brijesh.singh@....com
Subject: Re: [PATCH v2 2/4] mm: x86: Invoke hypercall when page encryption status is changed

On Wed, May 12, 2021, at 6:15 AM, Borislav Petkov wrote:
> On Fri, Apr 23, 2021 at 03:58:43PM +0000, Ashish Kalra wrote:
> > +static inline void notify_page_enc_status_changed(unsigned long pfn,
> > +						  int npages, bool enc)
> > +{
> > +	PVOP_VCALL3(mmu.notify_page_enc_status_changed, pfn, npages, enc);
> > +}
> 
> Now the question is whether something like that is needed for TDX, and,
> if so, could it be shared by both.

The TDX MapGPA call can fail, and presumably it will fail if the page is not sufficiently quiescent from the host's perspective.  It seems like a mistake to me to have a KVM-specific hypercall for this that cannot cleanly fail.