All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Dave Martin <Dave.Martin@arm.com>,
	"David S. Miller" <davem@davemloft.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Evgeniy Stepanov <eugenis@google.com>,
	Graeme Barnes <Graeme.Barnes@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Kees Cook <keescook@chromium.org>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Kostya Serebryany <kcc@google.com>, Lee Smith <Lee.Smith@arm.com>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Shuah Khan <shuah@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
	Will Deacon <will.deacon@arm.com>
Subject: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Mon, 18 Mar 2019 16:35:31 +0000	[thread overview]
Message-ID: <20190318163533.26838-3-vincenzo.frascino@arm.com> (raw)
In-Reply-To: <20190318163533.26838-1-vincenzo.frascino@arm.com>

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>

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);
+
+	/* Write to a file */
+	write(fd, addr, sizeof(addr));
+
+	close(fd);
+}
+
-- 
2.21.0


WARNING: multiple messages have this Message-ID (diff)
From: vincenzo.frascino at arm.com (Vincenzo Frascino)
Subject: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Mon, 18 Mar 2019 16:35:31 +0000	[thread overview]
Message-ID: <20190318163533.26838-3-vincenzo.frascino@arm.com> (raw)
In-Reply-To: <20190318163533.26838-1-vincenzo.frascino@arm.com>

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 <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
CC: Andrey Konovalov <andreyknvl at google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>

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);
+
+	/* Write to a file */
+	write(fd, addr, sizeof(addr));
+
+	close(fd);
+}
+
-- 
2.21.0

WARNING: multiple messages have this Message-ID (diff)
From: vincenzo.frascino@arm.com (Vincenzo Frascino)
Subject: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Mon, 18 Mar 2019 16:35:31 +0000	[thread overview]
Message-ID: <20190318163533.26838-3-vincenzo.frascino@arm.com> (raw)
Message-ID: <20190318163531.D9oXsDqnBlEMpRcd8Od5nVzNO_yAMtufpqu_0a3epAI@z> (raw)
In-Reply-To: <20190318163533.26838-1-vincenzo.frascino@arm.com>

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 <catalin.marinas at arm.com>
Cc: Will Deacon <will.deacon at arm.com>
CC: Andrey Konovalov <andreyknvl at google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino at arm.com>

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);
+
+	/* Write to a file */
+	write(fd, addr, sizeof(addr));
+
+	close(fd);
+}
+
-- 
2.21.0

WARNING: multiple messages have this Message-ID (diff)
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Dave Martin <Dave.Martin@arm.com>,
	"David S. Miller" <davem@davemloft.net>,
	Dmitry Vyukov <dvyukov@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Evgeniy Stepanov <eugenis@google.com>,
	Graeme Barnes <Graeme.Barnes@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ingo Molnar <mingo@kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Kate Stewart <kstewart@linuxf>
Subject: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Mon, 18 Mar 2019 16:35:31 +0000	[thread overview]
Message-ID: <20190318163533.26838-3-vincenzo.frascino@arm.com> (raw)
In-Reply-To: <20190318163533.26838-1-vincenzo.frascino@arm.com>

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>

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);
+
+	/* Write to a file */
+	write(fd, addr, sizeof(addr));
+
+	close(fd);
+}
+
-- 
2.21.0

WARNING: multiple messages have this Message-ID (diff)
From: Vincenzo Frascino <vincenzo.frascino@arm.com>
To: linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org, linux-arch@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Kate Stewart <kstewart@linuxfoundation.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Kostya Serebryany <kcc@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Chintan Pandya <cpandya@codeaurora.org>,
	Shuah Khan <shuah@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	Jacob Bramley <Jacob.Bramley@arm.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Dave Martin <Dave.Martin@arm.com>,
	Evgeniy Stepanov <eugenis@google.com>,
	Kees Cook <keescook@chromium.org>,
	Ruben Ayrapetyan <Ruben.Ayrapetyan@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Graeme Barnes <Graeme.Barnes@arm.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Dmitry Vyukov <dvyukov@google.com>,
	Branislav Rankov <Branislav.Rankov@arm.com>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
	Lee Smith <Lee.Smith@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robin Murphy <robin.murphy@arm.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Subject: [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt
Date: Mon, 18 Mar 2019 16:35:31 +0000	[thread overview]
Message-ID: <20190318163533.26838-3-vincenzo.frascino@arm.com> (raw)
In-Reply-To: <20190318163533.26838-1-vincenzo.frascino@arm.com>

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 <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
CC: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>

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);
+
+	/* 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

  parent reply	other threads:[~2019-03-18 16:36 UTC|newest]

Thread overview: 224+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 19:51 [PATCH v11 00/14] arm64: untag user pointers passed to the kernel Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` andreyknvl
2019-03-15 19:51 ` [PATCH v11 01/14] uaccess: add untagged_addr definition for other arches Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 02/14] arm64: untag user pointers in access_ok and __uaccess_mask_ptr Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 03/14] lib, arm64: untag user pointers in strn*_user Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-18 11:33   ` Kevin Brodsky
2019-03-18 11:33     ` Kevin Brodsky
2019-03-18 11:33     ` Kevin Brodsky
2019-03-18 11:33     ` kevin.brodsky
2019-03-18 11:33   ` Kevin Brodsky
2019-03-15 19:51 ` [PATCH v11 04/14] mm, arm64: untag user pointers passed to memory syscalls Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 05/14] mm, arm64: untag user pointers in mm/gup.c Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` [PATCH v11 06/14] fs, arm64: untag user pointers in copy_mount_options Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 07/14] fs, arm64: untag user pointers in fs/userfaultfd.c Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` [PATCH v11 08/14] net, arm64: untag user pointers in tcp_zerocopy_receive Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 20:03   ` Eric Dumazet
2019-03-15 20:03     ` Eric Dumazet
2019-03-15 20:03     ` Eric Dumazet
2019-03-15 20:03     ` eric.dumazet
2019-03-18 13:14     ` Andrey Konovalov
2019-03-18 13:14       ` Andrey Konovalov
2019-03-18 13:14       ` Andrey Konovalov
2019-03-18 13:14       ` Andrey Konovalov
2019-03-18 13:14       ` Andrey Konovalov
2019-03-18 13:14       ` Andrey Konovalov
2019-03-18 13:14       ` andreyknvl
2019-03-18 13:16       ` Andrey Konovalov
2019-03-18 13:16         ` Andrey Konovalov
2019-03-18 13:16         ` Andrey Konovalov
2019-03-18 13:16         ` Andrey Konovalov
2019-03-18 13:16         ` Andrey Konovalov
2019-03-18 13:16         ` Andrey Konovalov
2019-03-18 13:16         ` andreyknvl
2019-03-18 14:44         ` Eric Dumazet
2019-03-18 14:44           ` Eric Dumazet
2019-03-18 14:44           ` Eric Dumazet
2019-03-18 14:44           ` Eric Dumazet
2019-03-18 14:44           ` Eric Dumazet
2019-03-18 14:44           ` Eric Dumazet
2019-03-18 14:44           ` edumazet
2019-03-18 16:08           ` Andrey Konovalov
2019-03-18 16:08             ` Andrey Konovalov
2019-03-18 16:08             ` Andrey Konovalov
2019-03-18 16:08             ` Andrey Konovalov
2019-03-18 16:08             ` Andrey Konovalov
2019-03-18 16:08             ` Andrey Konovalov
2019-03-18 16:08             ` andreyknvl
2019-03-15 20:03   ` Eric Dumazet
2019-03-15 19:51 ` [PATCH v11 09/14] kernel, arm64: untag user pointers in prctl_set_mm* Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-16 19:31   ` kbuild test robot
2019-03-16 19:31     ` kbuild test robot
2019-03-16 19:31     ` kbuild test robot
2019-03-18 16:53     ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` andreyknvl
2019-03-18 11:47   ` Kevin Brodsky
2019-03-18 11:47     ` Kevin Brodsky
2019-03-18 11:47     ` Kevin Brodsky
2019-03-18 11:47     ` kevin.brodsky
2019-03-18 16:53     ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` Andrey Konovalov
2019-03-18 16:53       ` andreyknvl
2019-03-18 11:47   ` Kevin Brodsky
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 10/14] tracing, arm64: untag user pointers in seq_print_user_ip Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 20:14   ` Steven Rostedt
2019-03-15 20:14     ` Steven Rostedt
2019-03-15 20:14     ` Steven Rostedt
2019-03-15 20:14     ` Steven Rostedt
2019-03-15 20:14     ` rostedt
2019-03-18 13:11     ` Andrey Konovalov
2019-03-18 13:11       ` Andrey Konovalov
2019-03-18 13:11       ` Andrey Konovalov
2019-03-18 13:11       ` Andrey Konovalov
2019-03-18 13:11       ` Andrey Konovalov
2019-03-18 13:11       ` Andrey Konovalov
2019-03-18 13:11       ` andreyknvl
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 11/14] uprobes, arm64: untag user pointers in find_active_uprobe Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` [PATCH v11 12/14] bpf, arm64: untag user pointers in stack_map_get_build_id_offset Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-15 19:51 ` [PATCH v11 13/14] arm64: update Documentation/arm64/tagged-pointers.txt Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-18 13:26   ` Kevin Brodsky
2019-03-18 13:26     ` Kevin Brodsky
2019-03-18 13:26     ` Kevin Brodsky
2019-03-18 13:26     ` kevin.brodsky
2019-03-18 16:59     ` Andrey Konovalov
2019-03-18 16:59       ` Andrey Konovalov
2019-03-18 16:59       ` Andrey Konovalov
2019-03-18 16:59       ` Andrey Konovalov
2019-03-18 16:59       ` Andrey Konovalov
2019-03-18 16:59       ` Andrey Konovalov
2019-03-18 16:59       ` andreyknvl
2019-03-18 13:26   ` Kevin Brodsky
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51 ` [PATCH v11 14/14] selftests, arm64: add a selftest for passing tagged pointers to kernel Andrey Konovalov
2019-03-15 19:51 ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` Andrey Konovalov
2019-03-15 19:51   ` andreyknvl
2019-03-18 16:35 ` [PATCH v2 0/4] arm64 relaxed ABI Vincenzo Frascino
2019-03-18 16:35   ` Vincenzo Frascino
2019-03-18 16:35   ` Vincenzo Frascino
2019-03-18 16:35   ` Vincenzo Frascino
2019-03-18 16:35   ` vincenzo.frascino
2019-03-18 16:35   ` [PATCH v2 1/4] elf: Make AT_FLAGS arch configurable Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` vincenzo.frascino
2019-03-18 16:35   ` Vincenzo Frascino [this message]
2019-03-18 16:35     ` [PATCH v2 2/4] arm64: Define Documentation/arm64/elf_at_flags.txt Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` vincenzo.frascino
2019-03-22  6:22     ` Amit Daniel Kachhap
2019-03-22  6:22       ` Amit Daniel Kachhap
2019-03-22  6:22       ` Amit Daniel Kachhap
2019-03-22  6:22       ` Amit Daniel Kachhap
2019-03-22  6:22       ` Amit Daniel Kachhap
2019-03-22  6:22       ` amit.kachhap
2019-03-22 10:48       ` Catalin Marinas
2019-03-22 10:48         ` Catalin Marinas
2019-03-22 10:48         ` Catalin Marinas
2019-03-22 10:48         ` Catalin Marinas
2019-03-22 10:48         ` catalin.marinas
2019-03-22 15:52     ` Kevin Brodsky
2019-03-22 15:52       ` Kevin Brodsky
2019-03-22 15:52       ` Kevin Brodsky
2019-03-22 15:52       ` Kevin Brodsky
2019-03-22 15:52       ` kevin.brodsky
2019-04-03 16:50       ` Catalin Marinas
2019-04-03 16:50         ` Catalin Marinas
2019-04-03 16:50         ` Catalin Marinas
2019-04-03 16:50         ` Catalin Marinas
2019-04-03 16:50         ` catalin.marinas
2019-04-12 14:16         ` Kevin Brodsky
2019-04-12 14:16           ` Kevin Brodsky
2019-04-12 14:16           ` Kevin Brodsky
2019-04-12 14:16           ` Kevin Brodsky
2019-04-12 14:16           ` kevin.brodsky
2019-03-18 16:35   ` [PATCH v2 3/4] arm64: Relax Documentation/arm64/tagged-pointers.txt Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` vincenzo.frascino
2019-03-18 16:35   ` [PATCH v2 4/4] arm64: elf: Advertise relaxed ABI Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` Vincenzo Frascino
2019-03-18 16:35     ` vincenzo.frascino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190318163533.26838-3-vincenzo.frascino@arm.com \
    --to=vincenzo.frascino@arm.com \
    --cc=Branislav.Rankov@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Graeme.Barnes@arm.com \
    --cc=Jacob.Bramley@arm.com \
    --cc=Lee.Smith@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Ruben.Ayrapetyan@arm.com \
    --cc=Szabolcs.Nagy@arm.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=ast@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=cpandya@codeaurora.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=edumazet@google.com \
    --cc=eugenis@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kcc@google.com \
    --cc=keescook@chromium.org \
    --cc=kevin.brodsky@arm.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luc.vanoostenryck@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=shuah@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.