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 82372C433F5 for ; Fri, 13 May 2022 09:14:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEE7C6B0073; Fri, 13 May 2022 05:14:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D762C8D0001; Fri, 13 May 2022 05:14:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF02B6B0078; Fri, 13 May 2022 05:14:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AA3A26B0073 for ; Fri, 13 May 2022 05:14:18 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 7015012094F for ; Fri, 13 May 2022 09:14:18 +0000 (UTC) X-FDA: 79460158596.31.8C7BAE2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 4AD30400B8 for ; Fri, 13 May 2022 09:13:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7B982621A5; Fri, 13 May 2022 09:14:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45CD1C34113; Fri, 13 May 2022 09:14:13 +0000 (UTC) Date: Fri, 13 May 2022 10:14:09 +0100 From: Catalin Marinas To: Thomas Gleixner Cc: Dave Hansen , "H.J. Lu" , Peter Zijlstra , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , the arch/x86 maintainers , Alexander Potapenko , Dmitry Vyukov , Andi Kleen , Rick Edgecombe , Linux-MM , LKML Subject: Re: [RFCv2 00/10] Linear Address Masking enabling Message-ID: References: <20220511022751.65540-1-kirill.shutemov@linux.intel.com> <20220511064943.GR76023@worktop.programming.kicks-ass.net> <20bada85-9203-57f4-2502-57a6fd11f3ea@intel.com> <875ymav8ul.ffs@tglx> <55176b79-90af-4a47-dc06-9f5f2f2c123d@intel.com> <87o802tjd7.ffs@tglx> <67aef839-0757-37b1-a42d-154c0116cbf5@intel.com> <878rr6te6b.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878rr6te6b.ffs@tglx> Authentication-Results: imf17.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf17.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4AD30400B8 X-Rspam-User: X-Stat-Signature: pnkoaph45oxmhosug1nezis1mt5ohgua X-HE-Tag: 1652433237-100147 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 Fri, May 13, 2022 at 03:27:24AM +0200, Thomas Gleixner wrote: > On Thu, May 12 2022 at 17:46, Dave Hansen wrote: > > On 5/12/22 17:08, H.J. Lu wrote: > > If I had to take a shot at this today, I think I'd opt for: > > > > mask = sys_enable_masking(bits=6, flags=FUZZY_NR_BITS); > > > > although I'm not super confident about the "fuzzy" flag. I also don't > > think I'd totally hate the "blind" interface where the kernel just gets > > to pick unilaterally and takes zero input from userspace. > > That's the only sane choice and you can make it simple for userspace: > > ret = prctl(GET_XXX_MASK, &mask); > > and then let it decide based on @ret and @mask whether to use it or not. Getting the mask would work for arm64 as well (it's always 0xffUL << 56, top-byte-ignore). Setting the mask from user space won't be of any use to us, it's baked in hardware. > But of course nobody thought about this as a generic feature and so we > have the ARM64 TBI muck as a precedence. > > So much for coordination and portability... Well, we had TBI in the architecture and enabled for user-space since the first arm64 kernel port (2012), no ABI controls needed. It had some specific uses like JITs to avoid masking out type bits encoded in pointers. In 2019 sanitisers appeared and we relaxed the TBI at the syscall level but, to avoid potentially confusing some programs, we added a control which only changes the behaviour of access_ok(). More of a safety thing, we might have as well skipped it. There is no hardware configuration toggled by this control, nor is the user address space layout (max 52-bit on arm64). Since sanitisers require compiler instrumentation (or, with MTE, arm64-specific libc changes), it's pretty much all within the arm64-specific user codebase. MTE came along and we added some more bits on top which, again, are hardware specific and contained within the arm64 libc startup code (tag checking modes etc). Dave indeed mentioned passing a mask to allow a more flexible control but, as already mentioned in the old thread, for arm64 the feature was already on, so it didn't make much sense, it seemed more like over-engineering. Had we known that Intel is pursing something similar, maybe we'd have designed the interface differently (we didn't get the hint). Intel's LAM has more flexibility but I don't see the arm64 TBI getting in the way. Just don't use it as an example because they evolved in different ways. I'm happy for arm64 to adopt a more flexible interface while keeping the current one around for backwards compatibility). But on arm64 we can't control the masking, not even disable it per process since it has always been on. > I'm so tired of this short sighted 'cram my feature in' approach of > _all_ involved parties. Unfortunately it happens occasionally, especially when developers can't disclose that their companies work on similar features (resctrl is a good example where arm64 would have benefited from a more generic approach but at the time MPAM was not public). -- Catalin