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 F0807C433EF for ; Thu, 10 Mar 2022 22:46:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 50A148D0002; Thu, 10 Mar 2022 17:46:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B9478D0001; Thu, 10 Mar 2022 17:46:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A9318D0002; Thu, 10 Mar 2022 17:46:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 2C9D58D0001 for ; Thu, 10 Mar 2022 17:46:31 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id DC76A604CB for ; Thu, 10 Mar 2022 22:46:30 +0000 (UTC) X-FDA: 79229962140.01.B2DBB53 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf26.hostedemail.com (Postfix) with ESMTP id 4753E140016 for ; Thu, 10 Mar 2022 22:46:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646952389; x=1678488389; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=GyPHG+6o6SQ+zoAb+LvVQuT3BEQ0NBaqyT3vnoNdJqo=; b=RZF8zXcKUHCtd/VqaFsUbSqPL8BwwZ8psujFE3k5iAJuMaRCFzzsCH2K YWjkgQhXPEyxobr6cBiCTYzozZH3SeH/JPjUsQare4iIk6cVrEF5u4a/3 EyGH6wgVF2eYEmCICwFUf2yOyPoSYfYxJJ8IRGon2PdV1KYrQfbhbTefl YlHQfEBY2VKF6zgTNF60kxNKJO6FjbqSPZqVwr3kQFwrd8LHsl00G1rRX 7hnZrJLAphkvT3n+EFHf+i5fu7e5jW98/W4XPWbYtEc70dZKvd4Kp5hif xiZPaBVo/mPPGMHbQTYvu/+ggdlr3xI5semlZMjr1Cornl1iSyY4E731V Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10282"; a="341828600" X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="341828600" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 14:46:27 -0800 X-IronPort-AV: E=Sophos;i="5.90,171,1643702400"; d="scan'208";a="511096709" Received: from rabiahus-mobl1.amr.corp.intel.com (HELO [10.251.7.204]) ([10.251.7.204]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Mar 2022 14:46:27 -0800 Message-ID: <4f5e149e-aa0b-d18b-3a91-6db15c2fab64@intel.com> Date: Thu, 10 Mar 2022 14:46:20 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: David Laight , 'Andrew Cooper' , Bharata B Rao , "linux-kernel@vger.kernel.org" Cc: "linux-mm@kvack.org" , "x86@kernel.org" , "kirill.shutemov@linux.intel.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "catalin.marinas@arm.com" , "will@kernel.org" , "shuah@kernel.org" , "oleg@redhat.com" , "ananth.narayan@amd.com" References: <20220310111545.10852-1-bharata@amd.com> <20220310111545.10852-4-bharata@amd.com> <7fccb7f2-fc88-993e-e1b2-919448844112@citrix.com> From: Dave Hansen Subject: Re: [RFC PATCH v0 3/6] x86: Enable Upper Address Ignore(UAI) feature In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 4753E140016 X-Stat-Signature: 4315db1yifb78bhgumjkdw67n571845o Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=RZF8zXcK; spf=none (imf26.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-HE-Tag: 1646952388-317583 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000005, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/10/22 14:37, David Laight wrote: > Just letting user address space be aliased a lot of times doesn't > seem like a security feature to me. > It must have some strange use case. This should have been in the changelogs... sheesh... Right now, address sanitizers keep pointer metadata in various spots. But, it requires recompiling apps and libraries. These compiler-based things are also so slow that production use is rare. These masking things (ARM TBI, AMD UAI, Intel LAM) _theoretically_ let you plumb enough metadata around with pointers to do address sanitizer implementations in production. I think LAM is the most sane of the three, but I'm biased.