From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1C26C433F5 for ; Thu, 12 May 2022 14:46:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BB966B0074; Thu, 12 May 2022 10:46:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 669F36B0075; Thu, 12 May 2022 10:46:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5282B6B0078; Thu, 12 May 2022 10:46:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B50846B0074 for ; Thu, 12 May 2022 10:46:13 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 8133C806B0 for ; Thu, 12 May 2022 14:46:13 +0000 (UTC) X-FDA: 79457366226.27.02CDE36 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf15.hostedemail.com (Postfix) with ESMTP id 3196CA00B0 for ; Thu, 12 May 2022 14:45:59 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652366769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R+F2xDGOsy2uquCq56PXknf31hnVzXI6nb9v3w4WcNc=; b=c53TXvAGB+EtpvdOoNmfuR9lzEdIKm0QmNBAMk2SgIX3RwNyRDMBJvdHBJ1k1FX8E33fWY ysvplNSDGPTBIOV01BnX9yC38LmZzDmKDgtSK9A+PtpUp6uEe8ePsoNc3amgBcShBOQcsk /lMD+55iveacdequgowysOXL/7IELtEW5Rqxg1cT23Jzzwpv93Vt7+3GhN/3/vgR9JR1XR H9gW0aDRKOSomB0bl+Llyf0IGkiKKs0n+vy4WvsDfoQnm66XBMflh8x0pjBzMCD/6mQAb3 baXso2XFHY9YmAEyn5aWPLJzkRNdoD7Ykkp9sL9//Ecn9AjGEAKGHvkJY3b4uA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652366769; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=R+F2xDGOsy2uquCq56PXknf31hnVzXI6nb9v3w4WcNc=; b=51Rwl7xI97zYkIYKObqfq0D2lBrxNyNt8Fo6OljjyqIfCVKXlBtGVBIkP60ilmj1kIi8Vp /5+omwMjwBN/HrDQ== To: Peter Zijlstra , "Kirill A. Shutemov" Cc: Dave Hansen , Andy Lutomirski , x86@kernel.org, Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFCv2 09/10] x86/mm: Add userspace API to enable Linear Address Masking In-Reply-To: <20220511072651.GV76023@worktop.programming.kicks-ass.net> References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511022751.65540-11-kirill.shutemov@linux.intel.com> <20220511072651.GV76023@worktop.programming.kicks-ass.net> Date: Thu, 12 May 2022 16:46:09 +0200 Message-ID: <87y1z6vmfi.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 3196CA00B0 X-Stat-Signature: ujetok1gy798gtxpc4wjhtfmz4ukfdgg Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=c53TXvAG; dkim=pass header.d=linutronix.de header.s=2020e header.b=51Rwl7xI; spf=pass (imf15.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de X-HE-Tag: 1652366759-145007 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 11 2022 at 09:26, Peter Zijlstra wrote: > On Wed, May 11, 2022 at 05:27:50AM +0300, Kirill A. Shutemov wrote: >> @@ -1013,8 +1017,23 @@ static long thread_feature_prctl(struct task_struct *task, int option, >> >> /* Handle ARCH_THREAD_FEATURE_ENABLE */ >> >> + if (features & (X86_THREAD_LAM_U48 | X86_THREAD_LAM_U57)) { >> + long ret; >> + >> + /* LAM is only available in long mode */ >> + if (in_32bit_syscall()) >> + return -EINVAL; > > So what happens if userspace sets up a 32bit code entry in the LDT and > does the LAM thing as a 64bit syscamm but then goes run 32bit code? AFAICS, nothing happens. The only requirements are CR4.PAE = 1, IA32_EFER.LME = 1. Those are unaffected from user space running 32bit code, no? 32bit code can't use 64bit pointers so it can't have metadata bits set. But x32 can and is excluded by the above too. So the whole muck must be conditional on CONFIG_X86_64=y and does not need any other restrictions IMO. Thanks, tglx