linux-kernel - Re: [PATCHv11.1 11/19] 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]

Date: Tue, 4 Jun 2024 08:47:22 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 Borislav Petkov <bp@...en8.de>
Cc: adrian.hunter@...el.com, ardb@...nel.org, ashish.kalra@....com,
 bhe@...hat.com, dave.hansen@...ux.intel.com, elena.reshetova@...el.com,
 haiyangz@...rosoft.com, hpa@...or.com, jun.nakajima@...el.com,
 kai.huang@...el.com, kexec@...ts.infradead.org, kys@...rosoft.com,
 linux-acpi@...r.kernel.org, linux-coco@...ts.linux.dev,
 linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org, ltao@...hat.com,
 mingo@...hat.com, peterz@...radead.org, rafael@...nel.org,
 rick.p.edgecombe@...el.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
 seanjc@...gle.com, tglx@...utronix.de, thomas.lendacky@....com,
 x86@...nel.org
Subject: Re: [PATCHv11.1 11/19] x86/tdx: Convert shared memory back to private
 on kexec

On 6/4/24 08:32, Kirill A. Shutemov wrote:
> What about the comment below?
> 
> 			/*
> 			 * One possible reason for the failure is if kexec raced
> 			 * with memory conversion. In this case shared bit in
> 			 * page table got set (or not cleared) during
> 			 * shared<->private conversion, but the page is actually
> 			 * private. So this failure is not going to affect the
> 			 * kexec'ed kernel.
> 			 *
> 			 * The only thing one can do at this point on failure
> 			 * at this point is panic. In absence of better options,
> 			 * it is reasonable to proceed, hoping the failure is a
> 			 * benign shared bit mismatch due to the race.
> 			 *
> 			 * Also, even if the failure is real and the page cannot
> 			 * be touched as private, the kdump kernel will boot
> 			 * fine as it uses pre-reserved memory. What happens
> 			 * next depends on what the dumping process does and
> 			 * there's a reasonable chance to produce useful dump
> 			 * on crash.
> 			 *
> 			 * Regardless, the print leaves a trace in the log to
> 			 * give a clue for debug.
> 			 */

It's rambling too much for my taste.

Let's boil this down to what matters:

 1. Failures to change encryption status here can lead a future kernel
    to touch shared memory with a private mapping
 2. That causes an immediate unrecoverable guest shutdown (right?)
 3. kdump kernels should not be affected since they have their own
    memory ranges and its encryption status is not being tweawked here
 4. The pr_err() may help make some sense out of #2 when it happens

I'm not sure the reason behind the failed conversion is important here.

I wouldn't mention panic().

We don't need to opine about what the next kernel might or might not do.