Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3259178pxb; Mon, 9 Nov 2020 06:47:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJwngwfeggKkWyVQxn1McfNGpArSrHjjZBOj5jOe9y0fUKD1EiswUgkATcYVc1C09+B4p4kE X-Received: by 2002:a17:906:6a15:: with SMTP id o21mr14847831ejr.305.1604933241354; Mon, 09 Nov 2020 06:47:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604933241; cv=none; d=google.com; s=arc-20160816; b=rn4dkjpD8H698YrPxIbmCvfAKBY/y22tJKw0qnQYJohTNhP6/Fuy9VK9egBFH8Qx+x 37n7BraNXTYSxU3b56PqIXyOqXjuJ1tPIe7f0uLj0Ot4hz2OG3Pe9aYj3aajFdTAvymj o0gkM3hyRxRZw9g5WHWe54xqlBsM2Bf6Vc8xCjcgc3gJo9YmG/QYoGwkGicpjPrubCQ/ GBaaDzt/XpT0DtP6d8uQ7RjjsVm/9RmsNQVKhf7aWtw5VBBbABmbMEtHjD2SQTq4tQDj xvpOo6hTuVu3MMClu/imGSjtkM2qYAdkmC+sVHstwSNnC0bcW9moXOTuyloKVF1z/U4W hVHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:references:in-reply-to:message-id:date:subject :cc:to:from:dkim-signature; bh=ryvWaG1782WKgVsMLYPwWu2kVN8a7+9SPhrGbXw+dpw=; b=O9Ge2H1jDU6rScvf74BcORncZzN+MdlhL6eUqDo1uVgHE2MFhHb9fdbXSLDMep3Lai YDfLz+NAxsdhioM5f4Rj8A69dGNSqyAuwEGRUQUPDuSAXBc+yHiq4Ez4Or+YR+d89Cnt djoN0u6BrGwR8iPJ6JhOBLn6daJYTtgS6i19vB/gJXH/r8VT9VAS6aoWtl9ZyQVewHvV t6pxfd94kB07AFieghUZi6cx0DDrPWu6Ri7QTPj4OauvEtKTkskuo60jsWwTSIgtxixS Xy18Zj9mYWR9w2WsS2gVuNob61jdvFKQ/U8MHfHd/IYeFJUDi+1Ba3FbcGZYXjJ3L8C8 vz+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=WB5vzAZJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si6591313eju.549.2020.11.09.06.46.57; Mon, 09 Nov 2020 06:47:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=WB5vzAZJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732195AbgKIOoZ (ORCPT + 99 others); Mon, 9 Nov 2020 09:44:25 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:35424 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731655AbgKIOoR (ORCPT ); Mon, 9 Nov 2020 09:44:17 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0A9EZH5c084263; Mon, 9 Nov 2020 14:43:56 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references; s=corp-2020-01-29; bh=ryvWaG1782WKgVsMLYPwWu2kVN8a7+9SPhrGbXw+dpw=; b=WB5vzAZJ5m92LhAAPfWK4KaZxViMvbXThnwxJFMtyGYnHvhGrJBId4sORjdArNcusJC4 P3Yywkqf6YzBE4VFobWLlIuvRdoFYAA6Szm4RISyGx0BvqnTylFQdb+mBnPyuchKv9I+ Cp73hjcosPtWfqgEffrcXkbuqnWvwnoaThHwoRFlPC/Jgp2VtPZ30KVGy0BVz80CkEtp 4AJghlUdGEG4LipHu8EQ5zvq9l4PD+Jk4/dag5fvJ/6/4qR10C/jmnoWKXGw/RhuSBe8 iTLzxhsTCM6NXetp2uiROWe8TOjLl2Ccj5PWbBqRVC24QEI0RUMSizgEtQCznvJBOgPr Uw== Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 34p72ece4j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 09 Nov 2020 14:43:56 +0000 Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0A9Ee5Ej154784; Mon, 9 Nov 2020 14:43:56 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 34p5gvbccg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 09 Nov 2020 14:43:56 +0000 Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0A9EhsBB032138; Mon, 9 Nov 2020 14:43:54 GMT Received: from linux.nl.oracle.com (/10.175.27.128) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 09 Nov 2020 06:43:54 -0800 From: Alexandre Chartre To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, thomas.lendacky@amd.com, jroedel@suse.de Cc: konrad.wilk@oracle.com, jan.setjeeilers@oracle.com, junaids@google.com, oweisse@google.com, rppt@linux.vnet.ibm.com, graf@amazon.de, mgross@linux.intel.com, kuzuno@gmail.com, alexandre.chartre@oracle.com Subject: [RFC][PATCH 23/24] x86/entry: Remove paranoid_entry and paranoid_exit Date: Mon, 9 Nov 2020 15:44:24 +0100 Message-Id: <20201109144425.270789-24-alexandre.chartre@oracle.com> X-Mailer: git-send-email 2.18.4 In-Reply-To: <20201109144425.270789-1-alexandre.chartre@oracle.com> References: <20201109144425.270789-1-alexandre.chartre@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9799 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=591 mlxscore=0 spamscore=0 phishscore=0 adultscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011090103 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9799 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=605 mlxscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 phishscore=0 priorityscore=1501 spamscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011090102 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The paranoid_entry and paranoid_exit assembly functions have been replaced by the kernel_paranoid_entry() and kernel_paranoid_exit() C functions. Now paranoid_entry/exit are not used anymore and can be removed. Signed-off-by: Alexandre Chartre --- arch/x86/entry/entry_64.S | 131 -------------------------------------- 1 file changed, 131 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 9ea8187d4405..797effbe65b6 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -882,137 +882,6 @@ SYM_CODE_START(xen_failsafe_callback) SYM_CODE_END(xen_failsafe_callback) #endif /* CONFIG_XEN_PV */ -/* - * Save all registers in pt_regs. Return GSBASE related information - * in EBX depending on the availability of the FSGSBASE instructions: - * - * FSGSBASE R/EBX - * N 0 -> SWAPGS on exit - * 1 -> no SWAPGS on exit - * - * Y GSBASE value at entry, must be restored in paranoid_exit - */ -SYM_CODE_START_LOCAL(paranoid_entry) - UNWIND_HINT_FUNC - cld - PUSH_AND_CLEAR_REGS save_ret=1 - ENCODE_FRAME_POINTER 8 - - /* - * Always stash CR3 in %r14. This value will be restored, - * verbatim, at exit. Needed if paranoid_entry interrupted - * another entry that already switched to the user CR3 value - * but has not yet returned to userspace. - * - * This is also why CS (stashed in the "iret frame" by the - * hardware at entry) can not be used: this may be a return - * to kernel code, but with a user CR3 value. - * - * Switching CR3 does not depend on kernel GSBASE so it can - * be done before switching to the kernel GSBASE. This is - * required for FSGSBASE because the kernel GSBASE has to - * be retrieved from a kernel internal table. - */ - SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14 - - /* - * Handling GSBASE depends on the availability of FSGSBASE. - * - * Without FSGSBASE the kernel enforces that negative GSBASE - * values indicate kernel GSBASE. With FSGSBASE no assumptions - * can be made about the GSBASE value when entering from user - * space. - */ - ALTERNATIVE "jmp .Lparanoid_entry_checkgs", "", X86_FEATURE_FSGSBASE - - /* - * Read the current GSBASE and store it in %rbx unconditionally, - * retrieve and set the current CPUs kernel GSBASE. The stored value - * has to be restored in paranoid_exit unconditionally. - * - * The unconditional write to GS base below ensures that no subsequent - * loads based on a mispredicted GS base can happen, therefore no LFENCE - * is needed here. - */ - SAVE_AND_SET_GSBASE scratch_reg=%rax save_reg=%rbx - ret - -.Lparanoid_entry_checkgs: - /* EBX = 1 -> kernel GSBASE active, no restore required */ - movl $1, %ebx - /* - * The kernel-enforced convention is a negative GSBASE indicates - * a kernel value. No SWAPGS needed on entry and exit. - */ - movl $MSR_GS_BASE, %ecx - rdmsr - testl %edx, %edx - jns .Lparanoid_entry_swapgs - ret - -.Lparanoid_entry_swapgs: - SWAPGS - - /* - * The above SAVE_AND_SWITCH_TO_KERNEL_CR3 macro doesn't do an - * unconditional CR3 write, even in the PTI case. So do an lfence - * to prevent GS speculation, regardless of whether PTI is enabled. - */ - FENCE_SWAPGS_KERNEL_ENTRY - - /* EBX = 0 -> SWAPGS required on exit */ - xorl %ebx, %ebx - ret -SYM_CODE_END(paranoid_entry) - -/* - * "Paranoid" exit path from exception stack. This is invoked - * only on return from non-NMI IST interrupts that came - * from kernel space. - * - * We may be returning to very strange contexts (e.g. very early - * in syscall entry), so checking for preemption here would - * be complicated. Fortunately, there's no good reason to try - * to handle preemption here. - * - * R/EBX contains the GSBASE related information depending on the - * availability of the FSGSBASE instructions: - * - * FSGSBASE R/EBX - * N 0 -> SWAPGS on exit - * 1 -> no SWAPGS on exit - * - * Y User space GSBASE, must be restored unconditionally - */ -SYM_CODE_START_LOCAL(paranoid_exit) - UNWIND_HINT_REGS - /* - * The order of operations is important. RESTORE_CR3 requires - * kernel GSBASE. - * - * NB to anyone to try to optimize this code: this code does - * not execute at all for exceptions from user mode. Those - * exceptions go through error_exit instead. - */ - RESTORE_CR3 scratch_reg=%rax save_reg=%r14 - - /* Handle the three GSBASE cases */ - ALTERNATIVE "jmp .Lparanoid_exit_checkgs", "", X86_FEATURE_FSGSBASE - - /* With FSGSBASE enabled, unconditionally restore GSBASE */ - wrgsbase %rbx - jmp restore_regs_and_return_to_kernel - -.Lparanoid_exit_checkgs: - /* On non-FSGSBASE systems, conditionally do SWAPGS */ - testl %ebx, %ebx - jnz restore_regs_and_return_to_kernel - - /* We are returning to a context with user GSBASE */ - SWAPGS_UNSAFE_STACK - jmp restore_regs_and_return_to_kernel -SYM_CODE_END(paranoid_exit) - /* * Save all registers in pt_regs, and switch GS if needed. */ -- 2.18.4