From nobody Mon Apr 29 18:28:17 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1574158402; cv=none; d=zoho.com; s=zohoarc; b=BJo4FttRu3VGAJujFjCsPdHemD1+KtEe6xVbLeXi9pYfddLr2Gu4RAoUx5wmg/XnztShSiTkjqqKfF+MP8HztpAPlWJOXPYnF4Iik/gehID8hi1TYDWd1FAqE0bw5/O8gerNLDtaE7loiUhqObei4HQcIxxFOoHn9c7t73DhSYc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1574158402; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Sender:Subject:To; bh=jvi56LrxlgkkZ9q8+8K0J+8EZowrwhudsdaGZSFcVZU=; b=glI8JeVb5JHQDRKyRw2B9nJUEx98UGHezLk2fqO2yp8OjA1AtAzQwRoYIz/gW3AegslVzsgj4/chX19mbUiMEpIBYRMM22MGeSPva0a3F+klO9r/LTeY2HG74lOS2hS4rNGJERpFAJgGHpvjFQa/N2z/dd/GVNTTeywgcumSOg4= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1574158402100206.20972165748015; Tue, 19 Nov 2019 02:13:22 -0800 (PST) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iX0Uf-0002fh-DW; Tue, 19 Nov 2019 10:12:21 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iX0Ud-0002fc-US for xen-devel@lists.xenproject.org; Tue, 19 Nov 2019 10:12:19 +0000 Received: from Galois.linutronix.de (unknown [2a0a:51c0:0:12e:550::1]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 10f64706-0ab5-11ea-b678-bc764e2007e4; Tue, 19 Nov 2019 10:12:18 +0000 (UTC) Received: from [5.158.153.53] (helo=tip-bot2.lab.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1iX0UX-0001XN-Bb; Tue, 19 Nov 2019 11:12:13 +0100 Received: from [127.0.1.1] (localhost [IPv6:::1]) by tip-bot2.lab.linutronix.de (Postfix) with ESMTP id E47B11C19C7; Tue, 19 Nov 2019 11:12:12 +0100 (CET) X-Inumbo-ID: 10f64706-0ab5-11ea-b678-bc764e2007e4 Date: Tue, 19 Nov 2019 10:12:12 -0000 From: "tip-bot2 for Jan Beulich" To: linux-tip-commits@vger.kernel.org MIME-Version: 1.0 Message-ID: <157415833282.12247.2847277914358020515.tip-bot2@tip-bot2> X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Precedence: bulk X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1, SHORTCIRCUIT=-0.0001 Subject: [Xen-devel] [tip: x86/urgent] x86/stackframe/32: Repair 32-bit Xen PV X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Reply-To: linux-kernel@vger.kernel.org Cc: Denys Vlasenko , Jan Beulich , Peter Zijlstra , Brian Gerst , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Borislav Petkov , Andy Lutomirski , "H. Peter Anvin" , "xen-devel@lists.xenproject.org" , Thomas Gleixner , Linus Torvalds , Ingo Molnar Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 189eb7f3d7ec70ceeaa195221ddfd95016e10ace Gitweb: https://git.kernel.org/tip/189eb7f3d7ec70ceeaa195221ddfd9501= 6e10ace Author: Jan Beulich AuthorDate: Mon, 18 Nov 2019 16:21:12 +01:00 Committer: Ingo Molnar CommitterDate: Tue, 19 Nov 2019 09:01:59 +01:00 x86/stackframe/32: Repair 32-bit Xen PV Once again RPL checks have been introduced which don't account for a 32-bit kernel living in ring 1 when running in a PV Xen domain. The case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3 as well to guard against future uses of the macro on a code path reachable when running in PV mode under Xen; I have to admit that I stopped at a certain point trying to figure out whether there are present ones. Signed-off-by: Jan Beulich Cc: Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: xen-devel@lists.xenproject.org Fixes: 3c88c692c287 ("x86/stackframe/32: Provide consistent pt_regs") Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_32.S | 4 ++-- arch/x86/include/asm/segment.h | 12 ++++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index f83ca5a..3f847d8 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -172,7 +172,7 @@ ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI .if \no_user_check =3D=3D 0 /* coming from usermode? */ - testl $SEGMENT_RPL_MASK, PT_CS(%esp) + testl $USER_SEGMENT_RPL_MASK, PT_CS(%esp) jz .Lend_\@ .endif /* On user-cr3? */ @@ -217,7 +217,7 @@ testl $X86_EFLAGS_VM, 4*4(%esp) jnz .Lfrom_usermode_no_fixup_\@ #endif - testl $SEGMENT_RPL_MASK, 3*4(%esp) + testl $USER_SEGMENT_RPL_MASK, 3*4(%esp) jnz .Lfrom_usermode_no_fixup_\@ =20 orl $CS_FROM_KERNEL, 3*4(%esp) diff --git a/arch/x86/include/asm/segment.h b/arch/x86/include/asm/segment.h index ac38929..6669164 100644 --- a/arch/x86/include/asm/segment.h +++ b/arch/x86/include/asm/segment.h @@ -31,6 +31,18 @@ */ #define SEGMENT_RPL_MASK 0x3 =20 +/* + * When running on Xen PV, the actual privilege level of the kernel is 1, + * not 0. Testing the Requested Privilege Level in a segment selector to + * determine whether the context is user mode or kernel mode with + * SEGMENT_RPL_MASK is wrong because the PV kernel's privilege level + * matches the 0x3 mask. + * + * Testing with USER_SEGMENT_RPL_MASK is valid for both native and Xen PV + * kernels because privilege level 2 is never used. + */ +#define USER_SEGMENT_RPL_MASK 0x2 + /* User mode is privilege level 3: */ #define USER_RPL 0x3 =20 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel