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 1BEBDC433F5 for ; Fri, 1 Apr 2022 19:25:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A1936B0071; Fri, 1 Apr 2022 15:25:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6503B8D0002; Fri, 1 Apr 2022 15:25:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5192C8D0001; Fri, 1 Apr 2022 15:25:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id 3D5F26B0071 for ; Fri, 1 Apr 2022 15:25:36 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E17251833DE39 for ; Fri, 1 Apr 2022 19:25:25 +0000 (UTC) X-FDA: 79309289010.17.6ADFF90 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf04.hostedemail.com (Postfix) with ESMTP id 33A224000F for ; Fri, 1 Apr 2022 19:25:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1648841124; x=1680377124; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=1qdcczlKX4Qjv3s3lopzGh1+3WgMrjU6pxzvv7DskMU=; b=eI01janHOsQDF+Og23x5JZVO6xC5SmAEfhEox0A0SeU+Jvi1inFJMl/W JNLFWVy1BewXlbHr/Ae9sx6SXAn5YJP7T1CYT259w0YY+I1BAwCBZA3HW Fz2oXvY0wv6+x4bLLDBY3oLfyGTukr6UNLfH1bPTiJvXHjQzgFQLr6bXv 7JduJQMsRCy7O7SZFNSk26f8Ioukw5xDF4Df6gSox5mot/YAAOXFqEngD 84oazZslNmBg5U5E1JjXCb6Gu+0T94dsc1osbpuGXmNWHNNyb0nPsxWMV 3LGVFAUmVHRNSt76w4xgsv1Tw3p6faRmGsC9wFsJYPKt1jzrgJnOKCi/D Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10304"; a="259915104" X-IronPort-AV: E=Sophos;i="5.90,228,1643702400"; d="scan'208";a="259915104" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 12:25:22 -0700 X-IronPort-AV: E=Sophos;i="5.90,228,1643702400"; d="scan'208";a="567739894" Received: from dajones-mobl.amr.corp.intel.com (HELO [10.212.134.9]) ([10.212.134.9]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Apr 2022 12:25:22 -0700 Message-ID: Date: Fri, 1 Apr 2022 12:25:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: Bharata B Rao , Andy Lutomirski , Linux Kernel Mailing List Cc: linux-mm@kvack.org, the arch/x86 maintainers , "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Catalin Marinas , Will Deacon , shuah@kernel.org, Oleg Nesterov , ananth.narayan@amd.com References: <20220310111545.10852-1-bharata@amd.com> <6a5076ad-405e-4e5e-af55-fe2a6b01467d@www.fastmail.com> From: Dave Hansen Subject: Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: mqsy5xgti7puk4szh9xdn8qutn73pjgi Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=eI01janH; spf=none (imf04.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 33A224000F X-HE-Tag: 1648841123-579525 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/23/22 00:48, Bharata B Rao wrote: > Ok got that. However can you point to me a few instances in the current > kernel code where such assumption of high bit being user/kernel address > differentiator exists so that I get some idea of what it takes to > audit all such cases? Look around for comparisons against TASK_SIZE_MAX. arch/x86/lib/putuser.S or something like arch_check_bp_in_kernelspace() come to mind. > Also wouldn't the problem of high bit be solved by using only the > 6 out of 7 available bits in UAI and leaving the 63rd bit alone? > The hardware will still ignore the top bit, but this should take > care of the requirement of high bit being 0/1 for user/kernel in the > x86_64 kernel. Wouldn't that work? I don't think so. The kernel knows that a dereference of a pointer that looks like a kernel address that get kernel data. Userspace must be kept away from things that look like kernel addresses. Let's say some app does: void *ptr = (void *)0xffffffffc038d130; read(fd, ptr, 1); and inside the kernel, that boils down to: put_user('x', 0xffffffffc038d130); Today the kernels knows that 0xffffffffc038d130 is >=TASK_SIZE_MAX, so this is obviously naughty userspace trying to write to the kernel. But, it's not obviously wrong if the high bits are ignored. Like you said, we could, as a convention, check for the highest bit being set and use *that* to indicate a kernel address. But, the sneaky old userspace would just do: put_user('x', 0x7fffffffc038d130); It would pass the "high bit" check since that bit is clear, but it still accesses kernel memory because UAI ignores the bit userspace just cleared. I think the only way to get around this is to go find every single place in the kernel that does a userspace address check and ensure that it fully untags the pointer first. ... > However given that without a hardware feature like ARM64 MTE, this would > primarily be used in non-production environments. Hence I wonder if MSR > write cost could be tolerated? It would be great of the mysterious folks who asked both Intel and AMD for this feature could weigh in on this thread. But, I've been assuming that these features will be used to accelerate address sanitizers which used heavily today in non-production environments but are (generally) too slow for production. I'd be very surprised if folks wanted this snazzy new hardware feature from every CPU vendor on the planet just to speed up their non-production environments. I'd be less surprised if they wanted to expand the use of pointer tagging into more production environments.