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=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 F11DCC43381 for ; Fri, 22 Mar 2019 06:22:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7804218E2 for ; Fri, 22 Mar 2019 06:22:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727548AbfCVGWu (ORCPT ); Fri, 22 Mar 2019 02:22:50 -0400 Received: from foss.arm.com ([217.140.101.70]:38876 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbfCVGWt (ORCPT ); Fri, 22 Mar 2019 02:22:49 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C1CD15BE; Thu, 21 Mar 2019 23:22:49 -0700 (PDT) Received: from mail-it1-f181.google.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 238173F7F3; Thu, 21 Mar 2019 23:22:49 -0700 (PDT) Received: by mail-it1-f181.google.com with SMTP id m18so1904459ita.3; Thu, 21 Mar 2019 23:22:49 -0700 (PDT) X-Gm-Message-State: APjAAAX57onLFxYWJ+z/w/qGgpiyx8DohYCjQsd9YPJdaZ8rPJtK8oOu AnAOPUh6PlSWgYacAOILjOxbOuV3KvTrnFLJLkQ= X-Google-Smtp-Source: APXvYqx17vJkXgNLk1nwkLtg0pLwM6CJmZt3Y88GJ/ed1CPX/VX2QDTndGAwF9Sm+7co0cfjLo6Z/7McOEIBc7TPEu8= X-Received: by 2002:a24:5c47:: with SMTP id q68mr125583itb.81.1553235768373; Thu, 21 Mar 2019 23:22:48 -0700 (PDT) MIME-Version: 1.0 References: <20190318163533.26838-1-vincenzo.frascino@arm.com> <20190318163533.26838-3-vincenzo.frascino@arm.com> In-Reply-To: <20190318163533.26838-3-vincenzo.frascino@arm.com> From: Amit Daniel Kachhap Date: Fri, 22 Mar 2019 11:52:37 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt To: Vincenzo Frascino Cc: LAK , linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, Kate Stewart , Mark Rutland , Peter Zijlstra , Catalin Marinas , Will Deacon , Alexei Starovoitov , Kostya Serebryany , Eric Dumazet , Chintan Pandya , Shuah Khan , Ingo Molnar , Jacob Bramley , Daniel Borkmann , Szabolcs Nagy , Steven Rostedt , Dave Martin , Evgeniy Stepanov , Kees Cook , Ruben Ayrapetyan , Andrey Konovalov , Kevin Brodsky , Arnaldo Carvalho de Melo , Graeme Barnes , Alexander Viro , Dmitry Vyukov , Branislav Rankov , Ramana Radhakrishnan , Greg Kroah-Hartman , Luc Van Oostenryck , Lee Smith , Andrew Morton , Robin Murphy , "David S. Miller" , "Kirill A . Shutemov" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vincenzo, On Mon, Mar 18, 2019 at 10:06 PM Vincenzo Frascino wrote: > > On arm64 the TCR_EL1.TBI0 bit has been always enabled hence > the userspace (EL0) is allowed to set a non-zero value in the > top byte but the resulting pointers are not allowed at the > user-kernel syscall ABI boundary. > > With the relaxed ABI proposed through this document, it is now possible > to pass tagged pointers to the syscalls, when these pointers are in > memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap() or brk(). > > This change in the ABI requires a mechanism to inform the userspace > that such an option is available. > > Specify and document the way in which AT_FLAGS can be used to advertise > this feature to the userspace. > > Cc: Catalin Marinas > Cc: Will Deacon > CC: Andrey Konovalov > Signed-off-by: Vincenzo Frascino > > Squash with "arm64: Define Documentation/arm64/elf_at_flags.txt" > --- > Documentation/arm64/elf_at_flags.txt | 133 +++++++++++++++++++++++++++ > 1 file changed, 133 insertions(+) > create mode 100644 Documentation/arm64/elf_at_flags.txt > > diff --git a/Documentation/arm64/elf_at_flags.txt b/Documentation/arm64/elf_at_flags.txt > new file mode 100644 > index 000000000000..9b3494207c14 > --- /dev/null > +++ b/Documentation/arm64/elf_at_flags.txt > @@ -0,0 +1,133 @@ > +ARM64 ELF AT_FLAGS > +================== > + > +This document describes the usage and semantics of AT_FLAGS on arm64. > + > +1. Introduction > +--------------- > + > +AT_FLAGS is part of the Auxiliary Vector, contains the flags and it > +is set to zero by the kernel on arm64 unless one or more of the > +features detailed in paragraph 2 are present. > + > +The auxiliary vector can be accessed by the userspace using the > +getauxval() API provided by the C library. > +getauxval() returns an unsigned long and when a flag is present in > +the AT_FLAGS, the corresponding bit in the returned value is set to 1. > + > +The AT_FLAGS with a "defined semantics" on arm64 are exposed to the > +userspace via user API (uapi/asm/atflags.h). > +The AT_FLAGS bits with "undefined semantics" are set to zero by default. > +This means that the AT_FLAGS bits to which this document does not assign > +an explicit meaning are to be intended reserved for future use. > +The kernel will populate all such bits with zero until meanings are > +assigned to them. If and when meanings are assigned, it is guaranteed > +that they will not impact the functional operation of existing userspace > +software. Userspace software should ignore any AT_FLAGS bit whose meaning > +is not defined when the software is written. > + > +The userspace software can test for features by acquiring the AT_FLAGS > +entry of the auxiliary vector, and testing whether a relevant flag > +is set. > + > +Example of a userspace test function: > + > +bool feature_x_is_present(void) > +{ > + unsigned long at_flags = getauxval(AT_FLAGS); > + if (at_flags & FEATURE_X) > + return true; > + > + return false; > +} > + > +Where the software relies on a feature advertised by AT_FLAGS, it > +must check that the feature is present before attempting to > +use it. > + > +2. Features exposed via AT_FLAGS > +-------------------------------- > + > +bit[0]: ARM64_AT_FLAGS_SYSCALL_TBI > + > + On arm64 the TCR_EL1.TBI0 bit has been always enabled on the arm64 > + kernel, hence the userspace (EL0) is allowed to set a non-zero value > + in the top byte but the resulting pointers are not allowed at the > + user-kernel syscall ABI boundary. > + When bit[0] is set to 1 the kernel is advertising to the userspace > + that a relaxed ABI is supported hence this type of pointers are now > + allowed to be passed to the syscalls, when these pointers are in > + memory ranges privately owned by a process and obtained by the > + process in accordance with the definition of "valid tagged pointer" > + in paragraph 3. > + In these cases the tag is preserved as the pointer goes through the > + kernel. Only when the kernel needs to check if a pointer is coming > + from userspace an untag operation is required. > + > +3. ARM64_AT_FLAGS_SYSCALL_TBI > +----------------------------- > + > +From the kernel syscall interface prospective, we define, for the purposes > +of this document, a "valid tagged pointer" as a pointer that either it has > +a zero value set in the top byte or it has a non-zero value, it is in memory > +ranges privately owned by a userspace process and it is obtained in one of > +the following ways: > + - mmap() done by the process itself, where either: > + * flags = MAP_PRIVATE | MAP_ANONYMOUS > + * flags = MAP_PRIVATE and the file descriptor refers to a regular > + file or "/dev/zero" > + - a mapping below sbrk(0) done by the process itself > + - any memory mapped by the kernel in the process's address space during > + creation and following the restrictions presented above (i.e. data, bss, > + stack). > + > +When the ARM64_AT_FLAGS_SYSCALL_TBI flag is set by the kernel, the following > +behaviours are guaranteed by the ABI: > + > + - Every current or newly introduced syscall can accept any valid tagged > + pointers. > + > + - If a non valid tagged pointer is passed to a syscall then the behaviour > + is undefined. > + > + - Every valid tagged pointer is expected to work as an untagged one. > + > + - The kernel preserves any valid tagged pointers and returns them to the > + userspace unchanged in all the cases except the ones documented in the > + "Preserving tags" paragraph of tagged-pointers.txt. > + > +A definition of the meaning of tagged pointers on arm64 can be found in: > +Documentation/arm64/tagged-pointers.txt. > + > +Example of correct usage (pseudo-code) for a userspace application: > + > +bool arm64_syscall_tbi_is_present(void) > +{ > + unsigned long at_flags = getauxval(AT_FLAGS); > + if (at_flags & ARM64_AT_FLAGS_SYSCALL_TBI) > + return true; > + > + return false; > +} > + > +void main(void) > +{ > + char *addr = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, > + MAP_ANONYMOUS, -1, 0); > + > + int fd = open("test.txt", O_WRONLY); > + > + /* Check if the relaxed ABI is supported */ > + if (arm64_syscall_tbi_is_present()) { > + /* Add a tag to the pointer */ > + addr = tag_pointer(addr); > + } > + > + strcpy("Hello World\n", addr); Nit: s/strcpy("Hello World\n", addr)/strcpy(addr, "Hello World\n") Thanks, Amit D > + > + /* Write to a file */ > + write(fd, addr, sizeof(addr)); > + > + close(fd); > +} > + > -- > 2.21.0 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel