linux-kernel - Re: [PATCH] x86/mm/cpa: Warn if set_memory

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: <3936d8f9abaf8eba98963a13ad75024931aeb930.camel@intel.com>
Date:   Fri, 27 Oct 2023 16:46:39 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "Lutomirski, Andy" <luto@...nel.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "thomas.lendacky@....com" <thomas.lendacky@....com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Cui, Dexuan" <decui@...rosoft.com>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "mikelley@...rosoft.com" <mikelley@...rosoft.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "bp@...en8.de" <bp@...en8.de>,
        "sathyanarayanan.kuppuswamy@...ux.intel.com" 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86/mm/cpa: Warn if set_memory_XXcrypted() fails

On Fri, 2023-10-27 at 16:37 +0000, Michael Kelley (LINUX) wrote:
> When a caller gets an error from set_memory_decrypted(), it will
> take steps to try to get the memory back into a "good" state so
> that it can put the memory back on the free list.   If it can't get
> the memory back into a good state, then it will leak the memory.
> I was thinking about how the caller will make that determination.
> Is it based on whether set_memory_encrypted() succeeds?  I think
> that works, as long as (for x86 at least) set_memory_encrypted()
> ensures that the guest PTEs are all marked "private" before it
> returns success.
> 
> So maybe my comment applies to the caller in the sense of
> understanding what steps the caller should take to recover from
> an error, and the possible outcomes from the attempted recovery.

Since I was dropping free_decrypted_pages() helper, I was thinking to
actually just leak the pages if set_memory_decryted() fails. As in, not
try to recover them with set_memory_encrypted(). So the kernel will do
the 3 retries that the recent HyperV focused patch added, and then walk
away.

The kernel will already be warning about this situation, so we are not
expecting for it to be common. For rare cases, it seems simpler to just
leak it, and then set_memory_encrypted() can be simpler as it doesn't
need to worry about handling mixed ranges returning success.

I'll update the log to clarify the importance of the PTE being marked
shared in the guest, and post a v2.