Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1697765 > unrolled thread

Re: [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on successive kexecs

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on  successive kexecs Ingo Molnar <mingo@kernel.org> - 2017-07-27 09:20 +0200
    Re: [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on  successive kexecs Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-27 19:40 +0200

#1697765 — Re: [PATCH v1 1/2] x86/mm, kexec: Fix memory corruption with SME on successive kexecs

* Tom Lendacky <thomas.lendacky@amd.com> wrote:

> After issuing successive kexecs it was found that the SHA hash failed
> verification when booting the kexec'd kernel.  When SME is enabled, the
> change from using pages that were marked encrypted to now being marked as
> not encrypted (through new identify mapped page tables) results in memory
> corruption if there are any cache entries for the previously encrypted
> pages. This is because separate cache entries can exist for the same
> physical location but tagged both with and without the encryption bit.
> 
> To prevent this, issue a wbinvd before copying the pages from the source
> location to the destination location to clear any possible cache entry
> conflicts.
> 
> Cc: <kexec@lists.infradead.org>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
>  arch/x86/kernel/relocate_kernel_64.S | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S
> index 98111b3..c11d8bc 100644
> --- a/arch/x86/kernel/relocate_kernel_64.S
> +++ b/arch/x86/kernel/relocate_kernel_64.S
> @@ -132,6 +132,13 @@ identity_mapped:
>  	/* Flush the TLB (needed?) */
>  	movq	%r9, %cr3
>  
> +	/*
> +	 * If SME is/was active, there could be old encrypted cache line
> +	 * entries that will conflict with the now unencrypted memory
> +	 * used by kexec. Flush the caches before copying the kernel.
> +	 */
> +	wbinvd

WBINVD is very expensive IIRC - several milliseconds.

So if we change the page table from encrypted to unencrypted we need to do a full 
cache flush sounds pretty broken to me - how can then this be done via an API such 
as mmap() without executing WBINVD?

Thanks,

	Ingo

[toc] | [next] | [standalone]

#1698216

On Thu, Jul 27, 2017 at 7:15 AM, Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> I can #ifdef the wbinvd based on whether AMD_MEM_ENCRYPT is configured
> or not so that the wbinvd is avoided if not configured.

I suspect an ifdef will be useless, since things like distro kernels
tend to enable everything.

So it should probably be disabled dynamically, and only done if the
AMD memory encryption thing has actually been active.

[ There have also been various actual errata with wbinvd, so there
tends to be a non-performance reason to try to avoid it unless
strictly required ]

               Linus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web