* Tom Lendacky <thomas.lendacky at 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 at lists.infradead.org> > Signed-off-by: Tom Lendacky <thomas.lendacky at 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
