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 1CEE3C433EF for ; Mon, 14 Mar 2022 07:04:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 90A638D0003; Mon, 14 Mar 2022 03:04:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B9698D0001; Mon, 14 Mar 2022 03:04:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 781848D0003; Mon, 14 Mar 2022 03:04:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 660F28D0001 for ; Mon, 14 Mar 2022 03:04:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3710E21E55 for ; Mon, 14 Mar 2022 07:04:09 +0000 (UTC) X-FDA: 79242102618.14.0A50E05 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf31.hostedemail.com (Postfix) with ESMTP id 1581520035 for ; Mon, 14 Mar 2022 07:04:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647241448; x=1678777448; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=ZNQQbWtwZdlcGaOwYgxLMUCbM4F4zJI+ljHGsNI3jQI=; b=PsNa1Tx1LS9XsXC5QzxuynVLGW75XQrSpJj1ETLXt3kDsItRE6LxY2nO U25x8tmOxE47zFMfPyyuYo7pmqrHWozCqgYkvfh6Mr5O20q5DSr53miqJ CTXbaFpdS+sWRvoJbS/Jey76QlJGVm0LOQOeRKL2BSkxXC06f54MayOSN fexxDOiMKO/oo0oouJEmW6Q0M8nSMd2J4uqdE1V8c+Mgs3kG/VdGbFJD2 OSjoj9wZDGeLU/RxgGCLURczq9KOzwWbhKL2r4O75cX9UC4dUTaOOfgnC QyKfD4zVqq1nwVrQ/80AfryUoqnTxdxLwSq6+0Rx1OUY/DnTpCd7YXWeT w==; X-IronPort-AV: E=McAfee;i="6200,9189,10285"; a="253512147" X-IronPort-AV: E=Sophos;i="5.90,179,1643702400"; d="scan'208";a="253512147" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2022 00:04:06 -0700 X-IronPort-AV: E=Sophos;i="5.90,179,1643702400"; d="scan'208";a="515301871" Received: from zborja-mobl1.amr.corp.intel.com (HELO [10.212.239.199]) ([10.212.239.199]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Mar 2022 00:04:06 -0700 Message-ID: <1a8ffb1a-d948-0a02-33d5-c332d3e2c228@intel.com> Date: Mon, 14 Mar 2022 00:03:57 -0700 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: 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> <81b6f618-05bc-f7d0-5461-4c3f0ca42d3f@intel.com> <57338b2a-291c-c7e7-57d5-86a8468b619f@amd.com> From: Dave Hansen Subject: Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging In-Reply-To: <57338b2a-291c-c7e7-57d5-86a8468b619f@amd.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1581520035 X-Rspam-User: Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=PsNa1Tx1; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf31.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com X-Stat-Signature: 4go6xdh99c17sqhrcqz8jnasoami4bue X-Rspamd-Server: rspam04 X-HE-Tag: 1647241447-377747 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 3/13/22 22:00, Bharata B Rao wrote: > On 3/10/2022 8:46 PM, Dave Hansen wrote:> 1. While Intel LAM provides two LAM widths (15 and 6 bits wide), AMD UAI > has a fixed tag width of 7 bits. This results in following differences > in the implementation: > - Two threadinfo flags (TIF_LAM_57 and TIF_LAM_48) in Intel LAM vs > single flag TIF_TAGGED_ADDR(like in ARM64) in AMD UAI. > - Untagging needs to be aware of 2 widths in Intel LAM as against > a single width in AMD UAI. I'd be perfectly happy with an initial version of this stuff that only comprehends UAI and LAM_57. As long as the ABI can be used for all three cases, adding the two most similar ones initially would make a lot of sense. > - Requirement of making LAM_U48 and mappings above 47bits mutually > exclusive is required for Intel LAM only. > > 2. The enablement bit is part of CR3 in Intel LAM which brings in > additional complexity of updating the CR3 with right LAM mode on every > MM switch and associated tlbstate changes. In AMD UAI, enablement bit > is part of EFER MSR and it is a single time enablement with no MM switch > time changes. Hold on a sec. The context-switching is a *policy*. A _kernel_ policy. If we wanted the LAM settings to be static and system wide, we'd just have a single: if (cpu_feature_enabled(LAM)) cr3 |= LAM_MASK; in build_cr3(). That's not exactly complicated. You know what's a heck of a lot more complicated than that? Adding context-switching for EFER. I can't imagine a world where we want this tagging to be system-wide. There *ARE* going to be apps that break with this pointer tagging stuff. Normal, user apps. Apps in containers. With a system-wide setting, they have zero recourse when things break. All a user can do is reboot the kernel. As-is, it seems like it would be awful to even develop apps that use tagging. You always want to test them with tagging on and off. With this, you need to reboot to test either way. Also, the prctl() in Kirill's version actually enables and disables the hardware feature in addition to the in-kernel tag/untag operations. This series takes the same ABI and doesn't change the hardware feature state. That will need to be rectified at some point. Speaking of which, it's also really worrying that kernel behavior is affected by _EFER_UAI. When tagging is "disabled" in the prctl(), _EFER_UAI is still set. The kernel can go merrily dereferencing both kernel and userspace pointers with no canonical checks. That seems scary. LAM's supervisor separation makes things a lot less scary.