Received: by 10.223.176.46 with SMTP id f43csp2652627wra; Mon, 22 Jan 2018 00:57:18 -0800 (PST) X-Google-Smtp-Source: AH8x227I3eG3Mcw2LcINzrOdI4h7C/IHR5RF9HFz0mH+VdsEe1nFICyTpU3Z8iO7Ibte25PZERLZ X-Received: by 10.99.97.210 with SMTP id v201mr7019371pgb.344.1516611437994; Mon, 22 Jan 2018 00:57:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516611437; cv=none; d=google.com; s=arc-20160816; b=tZ3ht8xHIEnMEd8WX4AFBaIWDicdyEKpFZIUb1ftWmYPCDJzMOTlYzjZ4pvoXIRdrN 9hZqzV8wOpoMaLmErv5R6iCVv7aTIkHUNQd5FxatBoZinXB44MpwE6pq142dXW+8SwQ2 ce0UtiplwVRzC3Zh6gsMWb5MjgU17ZeWIVhWOMjDY0dQ5SfCNhYcNZyIq+UzgGH93Mwo VGyftr7JEKFhqrpiz99/U5idDLhbf4yD69LwnpUr83cDj05Eu66oj9rdd2EqLEmokyTz Cw4nxDBSMP0VbcY9jNhS5Aovj1SJ6zuC8880urakjCgVIMq8uE5vPkOemD2AJwUoQL+8 fsYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=S3qKS9yQpVxTN8BbCivFI9IkZUncLCUvaVXQ0QVlXPk=; b=VrntVTBHbNIlODOhON1tuxKckYW2b2rZreROSLmOUpt1qLggwlPHu6+2NMcNq9uiLt 5ITrB3tMI61dYgk3kmxhzE3DTRnaI06/oUncInUSJbnogGw3Sbv8b66N2OrVOR7UkOqJ Tap4ibypj8w4zjF5xfmyMkMFrDxbKLaejP0ZGIJV/ah12LROcPGiicDsGr3KsqL2IwRE tPeSJT7dLWjOIpEBZOfyAeYEXPVvOE9EwQVAYjQDeWBre97Xbx6LNEQqlWE7vOsPFa3Y CBbAs4pk03+Xop+TdkP+EIfLI6IRXe+SB9R+01gCrWGsPQvbmK48CTAR7pkKRNrlRLr/ VMyA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x10si3353036pfi.400.2018.01.22.00.57.04; Mon, 22 Jan 2018 00:57:17 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753833AbeAVIyg (ORCPT + 99 others); Mon, 22 Jan 2018 03:54:36 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:34322 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753798AbeAVIyd (ORCPT ); Mon, 22 Jan 2018 03:54:33 -0500 Received: from localhost (LFbn-1-12258-90.w90-92.abo.wanadoo.fr [90.92.71.90]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id DEF45F45; Mon, 22 Jan 2018 08:54:32 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Young , Tom Lendacky , Thomas Gleixner , Juergen Gross , Tony Luck , Yu Chen , Baoquan He , Linus Torvalds , kexec@lists.infradead.org, ebiederm@redhat.com, Borislav Petkov , Rui Zhang , Arjan van de Ven , Boris Ostrovsky , Dan Williams Subject: [PATCH 4.14 87/89] x86/mm: Rework wbinvd, hlt operation in stop_this_cpu() Date: Mon, 22 Jan 2018 09:46:07 +0100 Message-Id: <20180122084003.212954389@linuxfoundation.org> X-Mailer: git-send-email 2.16.0 In-Reply-To: <20180122083954.683903493@linuxfoundation.org> References: <20180122083954.683903493@linuxfoundation.org> User-Agent: quilt/0.65 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Tom Lendacky commit f23d74f6c66c3697e032550eeef3f640391a3a7d upstream. Some issues have been reported with the for loop in stop_this_cpu() that issues the 'wbinvd; hlt' sequence. Reverting this sequence to halt() has been shown to resolve the issue. However, the wbinvd is needed when running with SME. The reason for the wbinvd is to prevent cache flush races between encrypted and non-encrypted entries that have the same physical address. This can occur when kexec'ing from memory encryption active to inactive or vice-versa. The important thing is to not have outside of kernel text memory references (such as stack usage), so the usage of the native_*() functions is needed since these expand as inline asm sequences. So instead of reverting the change, rework the sequence. Move the wbinvd instruction outside of the for loop as native_wbinvd() and make its execution conditional on X86_FEATURE_SME. In the for loop, change the asm 'wbinvd; hlt' sequence back to a halt sequence but use the native_halt() call. Fixes: bba4ed011a52 ("x86/mm, kexec: Allow kexec to be used with SME") Reported-by: Dave Young Signed-off-by: Tom Lendacky Signed-off-by: Thomas Gleixner Tested-by: Dave Young Cc: Juergen Gross Cc: Tony Luck Cc: Yu Chen Cc: Baoquan He Cc: Linus Torvalds Cc: kexec@lists.infradead.org Cc: ebiederm@redhat.com Cc: Borislav Petkov Cc: Rui Zhang Cc: Arjan van de Ven Cc: Boris Ostrovsky Cc: Dan Williams Link: https://lkml.kernel.org/r/20180117234141.21184.44067.stgit@tlendack-t1.amdoffice.net Signed-off-by: Greg Kroah-Hartman --- arch/x86/kernel/process.c | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) --- a/arch/x86/kernel/process.c +++ b/arch/x86/kernel/process.c @@ -380,19 +380,24 @@ void stop_this_cpu(void *dummy) disable_local_APIC(); mcheck_cpu_clear(this_cpu_ptr(&cpu_info)); + /* + * Use wbinvd on processors that support SME. This provides support + * for performing a successful kexec when going from SME inactive + * to SME active (or vice-versa). The cache must be cleared so that + * if there are entries with the same physical address, both with and + * without the encryption bit, they don't race each other when flushed + * and potentially end up with the wrong entry being committed to + * memory. + */ + if (boot_cpu_has(X86_FEATURE_SME)) + native_wbinvd(); for (;;) { /* - * Use wbinvd followed by hlt to stop the processor. This - * provides support for kexec on a processor that supports - * SME. With kexec, going from SME inactive to SME active - * requires clearing cache entries so that addresses without - * the encryption bit set don't corrupt the same physical - * address that has the encryption bit set when caches are - * flushed. To achieve this a wbinvd is performed followed by - * a hlt. Even if the processor is not in the kexec/SME - * scenario this only adds a wbinvd to a halting processor. + * Use native_halt() so that memory contents don't change + * (stack usage and variables) after possibly issuing the + * native_wbinvd() above. */ - asm volatile("wbinvd; hlt" : : : "memory"); + native_halt(); } }