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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D4EFC32751 for ; Wed, 7 Aug 2019 20:38:45 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E19B3217F4 for ; Wed, 7 Aug 2019 20:38:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oPTTczcT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E19B3217F4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bBErICjB6nd7mwQNbBDpnZb4g4gpTMk2y3dLuo7L/Rk=; b=oPTTczcToawyew u/rPNZZeQYjZvPfIFPC45BN1YSLls7vYWZgKKotY36qZ1eZ9lQS9NlZj9sXlT4g9eZIeZmtySLxBv mxbRVnfbbkkzu/dl2ttRHfdo3zo4xJMkQCtmbMuh1vGA+HDjS5i1qf+ehag4JyLeeolt61FrMQAdI FeVPdpv0Xf/90bCyK5neDl7i43CkmxK04xndqi83iCKQupG6GwARlk95h1I+9KDixJ1P1AbVk9zGO j8dykAvUgigQNfX0rZHeSL+r/NjkRnisiCruTknHM1l+juYlJd7mBJ2FNy/3rN3D5sYHo6DsMZkPa ydP6RterVAPep6ZxC2Ww==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hvShY-0003Vn-O8; Wed, 07 Aug 2019 20:38:28 +0000 Received: from mga09.intel.com ([134.134.136.24]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hvShV-0003UZ-Ds for linux-arm-kernel@lists.infradead.org; Wed, 07 Aug 2019 20:38:27 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2019 13:38:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,358,1559545200"; d="scan'208";a="165464108" Received: from ray.jf.intel.com (HELO [10.7.201.140]) ([10.7.201.140]) by orsmga007.jf.intel.com with ESMTP; 07 Aug 2019 13:38:16 -0700 Subject: Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst To: Catalin Marinas , linux-arm-kernel@lists.infradead.org References: <20190807155321.9648-1-catalin.marinas@arm.com> <20190807155321.9648-2-catalin.marinas@arm.com> From: Dave Hansen Openpgp: preference=signencrypt Autocrypt: addr=dave.hansen@intel.com; keydata= mQINBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABtEVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT6JAjgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lcuQINBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABiQIfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y Message-ID: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com> Date: Wed, 7 Aug 2019 13:38:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190807155321.9648-2-catalin.marinas@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190807_133825_508366_A6DDB40E X-CRM114-Status: GOOD ( 29.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Will Deacon , Vincenzo Frascino Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 8/7/19 8:53 AM, Catalin Marinas wrote: > +- mmap() done by the process itself (or its parent), where either: > + > + - flags have the **MAP_ANONYMOUS** bit set > + - the file descriptor refers to a regular file (including those returned > + by memfd_create()) or **/dev/zero** What's a "regular file"? ;) > +- brk() system call done by the process itself (i.e. the heap area between > + the initial location of the program break at process creation and its > + current location). > + > +- any memory mapped by the kernel in the address space of the process > + during creation and with the same restrictions as for mmap() above (e.g. > + data, bss, stack). > + > +The AArch64 Tagged Address ABI is an opt-in feature and an application can > +control it via **prctl()** as follows: > + > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address > + ABI for the calling process. > + > + The (unsigned int) arg2 argument is a bit mask describing the control mode > + used: > + > + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default > + status is disabled. > + > + The arguments arg3, arg4, and arg5 are ignored. For previous prctl()'s, we've found that it's best to require that the unused arguments be 0. Without that, apps are free to put garbage there, which makes extending the prctl to use other arguments impossible in the future. Also, shouldn't this be converted over to an arch_prctl()? > +The prctl(PR_SET_TAGGED_ADDR_CTRL, ...) will return -EINVAL if the > +AArch64 Tagged Address ABI is not available > +(CONFIG_ARM64_TAGGED_ADDR_ABI disabled or sysctl abi.tagged_addr=0). > + > +The ABI properties set by the mechanism described above are inherited by > +threads of the same application and fork()'ed children but cleared by > +execve(). What is the scope of these prctl()'s? Are they thread-scoped or process-scoped? Can two threads in the same process run with different tagging ABI modes? > +Opting in (the prctl() option described above only) to or out of the > +AArch64 Tagged Address ABI can be disabled globally at runtime using the > +sysctl interface: > + > +- **abi.tagged_addr**: a new sysctl interface that can be used to prevent > + applications from enabling or disabling the relaxed ABI. The sysctl > + supports the following configuration options: > + > + - **0**: disable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to > + enable/disable the AArch64 Tagged Address ABI globally > + > + - **1** (Default): enable the prctl(PR_SET_TAGGED_ADDR_CTRL) option to > + enable/disable the AArch64 Tagged Address ABI globally > + > + Note that this sysctl does not affect the status of the AArch64 Tagged > + Address ABI of the running processes. Shouldn't the name be "abi.tagged_addr_control" or something? It actually has *zero* direct effect on tagged addresses in the ABI. What's the reason for allowing it to be toggled at runtime like this? Wouldn't it make more sense to just have it be a boot option so you *know* what the state of individual processes is? > +When a process has successfully enabled the new ABI by invoking > +prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE), the following > +behaviours are guaranteed: > + > +- Every currently available syscall, except the cases mentioned in section > + 3, can accept any valid tagged pointer. The same rule is applicable to > + any syscall introduced in the future. > + > +- The syscall behaviour is undefined for non valid tagged pointers. Do you really mean "undefined"? I mean, a bad pointer is a bad pointer. Why should it matter if it's a tagged bad pointer or an untagged bad pointer? ... > +A definition of the meaning of tagged pointers on AArch64 can be found in: > +Documentation/arm64/tagged-pointers.txt. > + > +3. AArch64 Tagged Address ABI Exceptions > +----------------------------------------- > + > +The behaviour described in section 2, with particular reference to the > +acceptance by the syscalls of any valid tagged pointer, is not applicable > +to the following cases: This is saying things in a pretty roundabout manner. Can't it just say: "The following cases do not accept tagged pointers:" > +- mmap() addr parameter. > + > +- mremap() new_address parameter. Is munmap() missing? Or was there a reason for leaving it out? > +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and > + PR_SET_MM_MAP_SIZE. > + > +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields. > + > +Any attempt to use non-zero tagged pointers will lead to undefined > +behaviour. I wonder if you want to generalize this a bit. I think you're saying that parts of the ABI that modify the *layout* of the address space never accept tagged pointers. > +4. Example of correct usage > +--------------------------- > +.. code-block:: c > + > + void main(void) > + { > + static int tbi_enabled = 0; > + unsigned long tag = 0; > + > + char *ptr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, > + MAP_ANONYMOUS, -1, 0); > + > + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, > + 0, 0, 0) == 0) > + tbi_enabled = 1; > + > + if (ptr == (void *)-1) /* MAP_FAILED */ > + return -1; > + > + if (tbi_enabled) > + tag = rand() & 0xff; > + > + ptr = (char *)((unsigned long)ptr | (tag << TAG_SHIFT)); > + > + *ptr = 'a'; > + > + ... > + } It looks like the TAG_SHIFT and tag size are pretty baked into the aarch64 architecture. But, are you confident that no future implementations will want different positions or sizes? (obviously controlled by other TCR_EL1 bits) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel