arm64: untag user pointers passed to the kernel

On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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.

This patch specifies and documents the way on which AT_FLAGS can be used to advertise this feature to the userspace.

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

CC Andrey Konovalov <[email protected]>

Signed-off-by Vincenzo Frascino <[email protected]>

---
 Documentation/arm64/elf_at_flags.txt | 111 +++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)
 create mode 100644 Documentation/arm64/elf_at_flags.txt

Documentation/arm64/elf_at_flags.txt new file +49 -0

new file mode 100644
index 000000000000..153e657c058a
@@ -0,0 +1,111 @@
+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 currently set to zero by the kernel on arm64.
+
+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 semantic" 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
+should check that the feature is present before attempting to
+use it.
+
+2. Features exposed via AT_FLAGS
+--------------------------------
+

Documentation/arm64/elf_at_flags.txt new file +12 -0

+
+3. ARM64_AT_FLAGS_SYSCALL_TBI
+-----------------------------
+
+When ARM64_AT_FLAGS_SYSCALL_TBI is enabled every syscalls can accept tagged
+pointers, when these pointers are in memory ranges obtained by an anonymous
+(MAP_ANONYMOUS) mmap() or brk().
+
+A definition of the meaning of tagged pointers on arm64 can be found in:
+Documentation/arm64/tagged-pointers.txt.
+
+When a pointer does not are in a memory range obtained by an anonymous mmap()

Quoted 5 lines · Vincenzo Frascino

On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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.

Quoted 3 lines

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().

What about other anonymous memory such as the process stack?

What about MAP_PRIVATE mappings of /dev/zero (i.e., oldskool "anonymous" mappings)?

I wonder whether this should really say MAP_PRIVATE rather than MAP_ANONYMOUS. There are two requirements here:

* the memory must be the exclusive property of a single process, otherwise tagging it on-the-fly could break some other process;

* the memory should be regular memory, i.e., not something like a mapped device. Since copy-on-write mappings of devices make little sense, and we want writes to devices to propagate to the hardware directly, MAP_PRIVATE doesn't make a lot of sense for such mappings.

I'm assuming here that tagging some currently shared copy-on-write pages would throw a page fault and trigger a copy, so that we end up tagging the calling process's private copy of the page.

I also don't see how the above requirements conflict with regular file- backed mappings (which would need to work if you want to be able to tag objects in .bss or .data etc.)

Quoted 70 lines

This change in the ABI requires a mechanism to inform the userspace that such an option is available.

This patch specifies and documents the way on which AT_FLAGS can be used to advertise this feature to the userspace.

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

CC Andrey Konovalov <[email protected]>

Signed-off-by Vincenzo Frascino <[email protected]>

---
 Documentation/arm64/elf_at_flags.txt | 111 +++++++++++++++++++++++++++
 1 file changed, 111 insertions(+)
 create mode 100644 Documentation/arm64/elf_at_flags.txt

Documentation/arm64/elf_at_flags.txt new file +49 -0

new file mode 100644
index 000000000000..153e657c058a
@@ -0,0 +1,111 @@
+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 currently set to zero by the kernel on arm64.
+
+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 semantic" 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
+should check that the feature is present before attempting to
+use it.
+
+2. Features exposed via AT_FLAGS
+--------------------------------
+

Documentation/arm64/elf_at_flags.txt line 59

Quoted 10 lines

Documentation/arm64/elf_at_flags.txt new file +10 -0

+bit[0]: ARM64_AT_FLAGS_SYSCALL_TBI
+
+    On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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 obtained by anonymous (MAP_ANONYMOUS) mmap() or brk().

"TBI" is a slightly odd name.

The kernel seems not to be ignoring the top byte, otherwise how could it make a difference whehter the memory is anonymous or something else?

(With memory tagging enabled, the top byte is also not architecturally ignored.)

Documentation/arm64/elf_at_flags.txt line 62

Quoted 3 lines

Documentation/arm64/elf_at_flags.txt new file +3 -0

+    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 (i.e. access_ok()) an untag operation is required.

Does the last sentence belong here? That's about kernel internals, whereas the rest all seems user-facing.

Quoted 16 lines

Documentation/arm64/elf_at_flags.txt new file +16 -0

+
+3. ARM64_AT_FLAGS_SYSCALL_TBI
+-----------------------------
+
+When ARM64_AT_FLAGS_SYSCALL_TBI is enabled every syscalls can accept tagged
+pointers, when these pointers are in memory ranges obtained by an anonymous
+(MAP_ANONYMOUS) mmap() or brk().
+
+A definition of the meaning of tagged pointers on arm64 can be found in:
+Documentation/arm64/tagged-pointers.txt.
+
+When a pointer does not are in a memory range obtained by an anonymous mmap()
+or brk(), this can not be passed to a syscall if it is tagged.
+
+To be more explicit: a syscall can accept pointers whose memory range is
+obtained by a non-anonymous mmap() or brk() if and only if the tag encoded in

Documentation/arm64/elf_at_flags.txt line 84

Quoted 6 lines

Documentation/arm64/elf_at_flags.txt new file +6 -0

+the top-byte is 0x00.
+
+When a new syscall is added, this can accept tagged pointers if and only if
+these pointers are in memory ranges obtained by an anonymous (MAP_ANONYMOUS)
+mmap() or brk(). In all the other cases, the tag encoded in the top-byte is
+expected to be 0x00.

Does this apply to kernel interfaces that are not syscalls?

And does it apply to ioctls in general (I think from discussions elsewhere that it can't).

What about things that flow through the kernel, like an si_value.sival_ptr that propagates from sigqueue(2) to the signal frame of the signalled thread, or registered with the kernel via aio_read(2)?

This kind of thing is why I would like to define a set of rules for making an educated guess about how the kernel should interpret arbitrary arguments (in an ideal world).

With issues like this in the mix, it seems difficult to extract general guarantees from ARM64_AT_FLAGS_SYSCALL_TBI. If it means that just certain specific uses of a few specific syscalls work with tagged pointers, that may not be very useful by ifself? It sounds like if you are tagging memory at all, you suddenly need to port every random library you're using.

[...]

Cheers
---Dave

On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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.

This patchset proposes a relaxation of the ABI and a mechanism to advertise it to the userspace via an AT_FLAGS.

The rationale behind the choice of AT_FLAGS is that the Unix System V ABI defines AT_FLAGS as "flags", leaving some degree of freedom in interpretation.
There are two previous attempts of using AT_FLAGS in the Linux Kernel for different reasons: the first was more generic and was used to expose the support for the GNU STACK NX feature [1] and the second was done for the MIPS architecture and was used to expose the support of "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" [2]. Both the changes are currently _not_ merged in mainline.
The only architecture that reserves some of the bits in AT_FLAGS is currently MIPS, which introduced the concept of platform specific ABI (psABI) reserving the top-byte [3].

When ARM64_AT_FLAGS_SYSCALL_TBI is set 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 they are in memory ranges obtained by anonymous mmap() or brk().

The userspace _must_ verify that the flag is set before passing tagged pointers to the syscalls allowed by this relaxation.

More in general, exposing the ARM64_AT_FLAGS_SYSCALL_TBI flag and mandating to the software to check that the feature is present, before using the associated functionality, it provides a degree of control on the decision of disabling such a feature in future without consequently breaking the userspace.

The change required a modification of the elf common code, because in Linux the AT_FLAGS are currently set to zero by default by the kernel.

The newly added flag has been verified on arm64 using the code below. #include <stdio.h>
#include <stdbool.h>
#include <sys/auxv.h>

#define ARM64_AT_FLAGS_SYSCALL_TBI (1 << 0)

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()

{
        if (arm64_syscall_tbi_is_present())
                printf("ARM64_AT_FLAGS_SYSCALL_TBI is present\n");
}

This patchset should be merged together with [4].

[1] https://patchwork.ozlabs.org/patch/579578/
[2] https://lore.kernel.org/patchwork/cover/618280/
[3] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/psABI_mips3.0.pdf
[4] https://patchwork.kernel.org/cover/10674351/

ABI References:
---------------
Sco SysV ABI: http://www.sco.com/developers/gabi/2003-12-17/contents.html
PowerPC AUXV: http://openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655242_98651.html
AMD64 ABI: https://www.cs.tufts.edu/comp/40-2012f/readings/amd64-abi.pdf
x86 ABI: https://www.uclibc.org/docs/psABI-i386.pdf
MIPS ABI: ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/psABI_mips3.0.pdf
ARM ABI: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf
SPARC ABI: http://math-atlas.sourceforge.net/devel/assembly/abi_sysV_sparc.pdf

Cc Catalin Marinas <[email protected]>

Cc Will Deacon <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Robin Murphy <[email protected]>

Cc Kees Cook <[email protected]>

Cc Kate Stewart <[email protected]>

Cc Greg Kroah-Hartman <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc "Kirill A . Shutemov" <[email protected]>

Cc Shuah Khan <[email protected]>

Cc Chintan Pandya <[email protected]>

Cc Jacob Bramley <[email protected]>

Cc Ruben Ayrapetyan <[email protected]>

Cc Andrey Konovalov <[email protected]>

Cc Lee Smith <[email protected]>

Cc Kostya Serebryany <[email protected]>

Cc Dmitry Vyukov <[email protected]>,

Cc Ramana Radhakrishnan <[email protected]>

Cc Luc Van Oostenryck <[email protected]>

Cc Evgeniy Stepanov <[email protected]>

CC Alexander Viro <[email protected]>

Signed-off-by Vincenzo Frascino <[email protected]>

Vincenzo Frascino (3):
elf: Make AT_FLAGS arch configurable
arm64: Define Documentation/arm64/elf_at_flags.txt
arm64: elf: Advertise relaxed ABI

 Documentation/arm64/elf_at_flags.txt  | 111 ++++++++++++++++++++++++++
 arch/arm64/include/asm/atflags.h      |   7 ++
 arch/arm64/include/asm/elf.h          |   5 ++
 arch/arm64/include/uapi/asm/atflags.h |   8 ++
 fs/binfmt_elf.c                       |   6 +-
 fs/binfmt_elf_fdpic.c                 |   6 +-
 fs/compat_binfmt_elf.c                |   5 ++
 7 files changed, 146 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/arm64/elf_at_flags.txt
 create mode 100644 arch/arm64/include/asm/atflags.h
 create mode 100644 arch/arm64/include/uapi/asm/atflags.h

--
2.19.2

Quoted 34 lines · Vincenzo Frascino

On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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.

This patchset proposes a relaxation of the ABI and a mechanism to advertise it to the userspace via an AT_FLAGS.

The rationale behind the choice of AT_FLAGS is that the Unix System V ABI defines AT_FLAGS as "flags", leaving some degree of freedom in interpretation.
There are two previous attempts of using AT_FLAGS in the Linux Kernel for different reasons: the first was more generic and was used to expose the support for the GNU STACK NX feature [1] and the second was done for the MIPS architecture and was used to expose the support of "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" [2]. Both the changes are currently _not_ merged in mainline.
The only architecture that reserves some of the bits in AT_FLAGS is currently MIPS, which introduced the concept of platform specific ABI (psABI) reserving the top-byte [3].

When ARM64_AT_FLAGS_SYSCALL_TBI is set 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 they are in memory ranges obtained by anonymous mmap() or brk().

The userspace _must_ verify that the flag is set before passing tagged pointers to the syscalls allowed by this relaxation.

More in general, exposing the ARM64_AT_FLAGS_SYSCALL_TBI flag and mandating to the software to check that the feature is present, before using the associated functionality, it provides a degree of control on the decision of disabling such a feature in future without consequently breaking the userspace.

Acked-by Andrey Konovalov <[email protected]>

Hi Andrey,

Quoted 36 lines · Andrey Konovalov

Quoted 34 lines · Vincenzo Frascino

On arm64 the TCR_EL1.TBI0 bit has been set since Linux 3.x 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.

This patchset proposes a relaxation of the ABI and a mechanism to advertise it to the userspace via an AT_FLAGS.

The rationale behind the choice of AT_FLAGS is that the Unix System V ABI defines AT_FLAGS as "flags", leaving some degree of freedom in interpretation.
There are two previous attempts of using AT_FLAGS in the Linux Kernel for different reasons: the first was more generic and was used to expose the support for the GNU STACK NX feature [1] and the second was done for the MIPS architecture and was used to expose the support of "MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking" [2]. Both the changes are currently _not_ merged in mainline.
The only architecture that reserves some of the bits in AT_FLAGS is currently MIPS, which introduced the concept of platform specific ABI (psABI) reserving the top-byte [3].

When ARM64_AT_FLAGS_SYSCALL_TBI is set 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 they are in memory ranges obtained by anonymous mmap() or brk().

The userspace _must_ verify that the flag is set before passing tagged pointers to the syscalls allowed by this relaxation.

More in general, exposing the ARM64_AT_FLAGS_SYSCALL_TBI flag and mandating to the software to check that the feature is present, before using the associated functionality, it provides a degree of control on the decision of disabling such a feature in future without consequently breaking the userspace.

[...]

Quoted 1 line

Acked-by Andrey Konovalov <[email protected]>

Thanks for the ack. However, if we go ahead with this ABI proposal it means that your patches need to be reworked to allow a non-zero top byte in all syscalls, including mmap() and friends, ioctl(). There are ABI concerns in either case but I'd rather have this discussion in the open. It doesn't necessarily mean that I endorse this proposal, I would like feedback and not just from kernel developers but user space ones.

The summary of our internal discussions (mostly between kernel developers) is that we can't properly describe a user ABI that covers future syscalls or syscall extensions while not all syscalls accept tagged pointers. So we tweaked the requirements slightly to only allow tagged pointers back into the kernel *if* the originating address is from an anonymous mmap() or below sbrk(0). This should cover some of the ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a pointer to a buffer obtained via mmap() on the device operations.

(sorry for not being clear on what Vincenzo's proposal implies)

Quoted 9 lines · Catalin Marinas

The summary of our internal discussions (mostly between kernel developers) is that we can't properly describe a user ABI that covers future syscalls or syscall extensions while not all syscalls accept tagged pointers. So we tweaked the requirements slightly to only allow tagged pointers back into the kernel *if* the originating address is from an anonymous mmap() or below sbrk(0). This should cover some of the ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a pointer to a buffer obtained via mmap() on the device operations.

Quoted 1 line

(sorry for not being clear on what Vincenzo's proposal implies)

OK, I see. So I need to make the following changes to my patchset AFAIU.

1. Make sure that we only allow tagged user addresses that originate from an anonymous mmap() or below sbrk(0). How exactly should this check be performed?

2. Allow tagged addressed passed to memory syscalls (as long as (1) is satisfied). Do I understand correctly that this means that I need to locate all find_vma() callers outside of mm/ and fix them up as well?

Quoted 14 lines · Andrey Konovalov

Quoted 10 lines · Catalin Marinas

The summary of our internal discussions (mostly between kernel developers) is that we can't properly describe a user ABI that covers future syscalls or syscall extensions while not all syscalls accept tagged pointers. So we tweaked the requirements slightly to only allow tagged pointers back into the kernel *if* the originating address is from an anonymous mmap() or below sbrk(0). This should cover some of the ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a pointer to a buffer obtained via mmap() on the device operations.

(sorry for not being clear on what Vincenzo's proposal implies)

OK, I see. So I need to make the following changes to my patchset AFAIU.

Quoted 3 lines

1. Make sure that we only allow tagged user addresses that originate from an anonymous mmap() or below sbrk(0). How exactly should this check be performed?

I don't think we should perform such checks. That's rather stating that the kernel only guarantees that the tagged pointers work if they originated from these memory ranges.

Quoted 3 lines

2. Allow tagged addressed passed to memory syscalls (as long as (1) is satisfied). Do I understand correctly that this means that I need to locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

BTW, I'll be off until the new year, so won't be able to follow up.

Quoted 12 lines · Catalin Marinas

Quoted 11 lines · Andrey Konovalov

Quoted 10 lines · Catalin Marinas

The summary of our internal discussions (mostly between kernel developers) is that we can't properly describe a user ABI that covers future syscalls or syscall extensions while not all syscalls accept tagged pointers. So we tweaked the requirements slightly to only allow tagged pointers back into the kernel *if* the originating address is from an anonymous mmap() or below sbrk(0). This should cover some of the ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a pointer to a buffer obtained via mmap() on the device operations.

(sorry for not being clear on what Vincenzo's proposal implies)

Quoted 8 lines

Quoted 5 lines

OK, I see. So I need to make the following changes to my patchset AFAIU.

1. Make sure that we only allow tagged user addresses that originate from an anonymous mmap() or below sbrk(0). How exactly should this check be performed?

I don't think we should perform such checks. That's rather stating that the kernel only guarantees that the tagged pointers work if they originated from these memory ranges.

I concur.

Really, the kernel should do the expected thing with all "non-weird" memory.

In lieu of a proper definition of "non-weird", I think we should have some lists of things that are explicitly included, and also excluded:

OK:
kernel-allocated process stack
brk area
MAP_ANONYMOUS | MAP_PRIVATE
MAP_PRIVATE mappings of /dev/zero

Not OK:
MAP_SHARED
mmaps of non-memory-like devices mmaps of anything that is not a regular file the VDSO
...

In general, userspace can tag memory that it "owns", and we do not assume a transfer of ownership except in the "OK" list above. Otherwise, it's the kernel's memory, or the owner is simply not well defined.

I would also like to see advice for userspace developers, particularly things like (strawman, please challenge!):

* Userspace should set tags at the point of allocation only.

* If you don't know how an object was allocated, you cannot modify the tag, period.

* A single C object should be accessed using a single, fixed pointer tag throughout its entire lifetime.

* Tags can be changed only when there are no outstanding pointers to the affected object or region that may be used to access the object or region (i.e., if the object were allocated from the C heap and is it safe to realloc() it, then it is safe to change the tag; for other types of allocation, analogous arguments can be applied).

* When the kernel dereferences a pointer on userspace's behalf, it shall behave equivalently to userspace dereferencing the same pointer, including use of the same tag (where passed by userspace).

* Where the pointer tag affects pointer dereference behaviour (i.e., with hardware memory colouring) the kernel makes no guarantee to honour pointer tags correctly for every location a buffer based on a pointer passed by userspace to the kernel.

(This means for example that for a read(fd, buf, size), we can check the tag for a single arbitrary location in *(char (*)[size])buf before passing the buffer to get_user_pages(). Hopefully this could be done in get_user_pages() itself rather than hunting call sites. For userspace, it means that you're on your own if you ask the kernel to operate on a buffer than spans multiple, independently- allocated objects, or a deliberately striped single object.)

* The kernel shall not extend the lifetime of user pointers in ways that are not clear from the specification of the syscall or interface to which the pointer is passed (and in any case shall not extend pointer lifetimes without good reason).

So no clever transparent caching between syscalls, unless it _really_ is transparent in the presence of tags.

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

We would need to get some cross-arch buy-in for this, otherwise core maintainers might just refuse to maintain the necessary guarantees.

Quoted 4 lines

Quoted 3 lines

2. Allow tagged addressed passed to memory syscalls (as long as (1) is satisfied). Do I understand correctly that this means that I need to locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

Also, watch out for code that pokes about inside struct vma directly.

I'm wondering, could we define an explicit type, say,

	struct user_vaddr {
		unsigned long addr;
	};

to replace the unsigned longs in struct vma the mm API? This would turn ad-hoc (unsigned long) casts into build breaks. We could have an explicit conversion functions, say,

	struct user_vaddr __user_vaddr_unsafe(void __user *);
	void __user *__user_ptr_unsafe(struct user_vaddr);

that we robotically insert in all the relevant places to mark unaudited code.

This allows us to keep the kernel buildable, while flagging things that will need review. We would also need to warn the mm folks to reject any new code using these unsafe conversions.

Of course, it would be a non-trivial effort...

Quoted 1 line

BTW, I'll be off until the new year, so won't be able to follow up.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 42 lines · Dave Martin

Quoted 12 lines · Catalin Marinas

Quoted 11 lines · Andrey Konovalov

Quoted 10 lines · Catalin Marinas

The summary of our internal discussions (mostly between kernel developers) is that we can't properly describe a user ABI that covers future syscalls or syscall extensions while not all syscalls accept tagged pointers. So we tweaked the requirements slightly to only allow tagged pointers back into the kernel *if* the originating address is from an anonymous mmap() or below sbrk(0). This should cover some of the ioctls or getsockopt(TCP_ZEROCOPY_RECEIVE) where the user passes a pointer to a buffer obtained via mmap() on the device operations.

(sorry for not being clear on what Vincenzo's proposal implies)

Quoted 8 lines

Quoted 5 lines

OK, I see. So I need to make the following changes to my patchset AFAIU.

1. Make sure that we only allow tagged user addresses that originate from an anonymous mmap() or below sbrk(0). How exactly should this check be performed?

I don't think we should perform such checks. That's rather stating that the kernel only guarantees that the tagged pointers work if they originated from these memory ranges.

I concur.

Really, the kernel should do the expected thing with all "non-weird" memory.

In lieu of a proper definition of "non-weird", I think we should have some lists of things that are explicitly included, and also excluded:

OK:
kernel-allocated process stack
brk area
MAP_ANONYMOUS | MAP_PRIVATE
MAP_PRIVATE mappings of /dev/zero

Not OK:
MAP_SHARED
mmaps of non-memory-like devices mmaps of anything that is not a regular file the VDSO
...

Quoted 3 lines

In general, userspace can tag memory that it "owns", and we do not assume a transfer of ownership except in the "OK" list above. Otherwise, it's the kernel's memory, or the owner is simply not well defined.

Agreed on the general idea: a process should be able to pass tagged pointers at the syscall interface, as long as they point to memory privately owned by the process. I think it would be possible to simplify the definition of "non-weird" memory by using only this "OK" list:
- mmap() done by the process itself, where either:
* flags = MAP_PRIVATE | MAP_ANONYMOUS
* flags = MAP_PRIVATE and fd refers to a regular file or a well-defined list of
device files (like /dev/zero)
- brk() done by the process itself
- Any memory mapped by the kernel in the new process's address space during execve(), with the same restrictions as above ([vdso]/[vvar] are therefore excluded)

Quoted 2 lines

I would also like to see advice for userspace developers, particularly things like (strawman, please challenge!):

To some extent, one could call me a userspace developer, so I'll try to help :)

Quoted 1 line

* Userspace should set tags at the point of allocation only.

Yes, tags are only supposed to be set at the point of either allocation or deallocation/reallocation. However, allocators can in principle be nested, so an allocator could take a region allocated by malloc() as input and subdivide it (changing tags in the process). That said, this suballocator must not free() that region until all the suballocations themselves have been freed (thereby restoring the tags initially set by malloc()).

Quoted 2 lines

* If you don't know how an object was allocated, you cannot modify the tag, period.

Agreed, allocators that tag memory can only operate on memory with a well-defined provenance (for instance anonymous mmap() or malloc()).

Quoted 2 lines

* A single C object should be accessed using a single, fixed pointer tag throughout its entire lifetime.

Agreed. Allocators themselves may need to be excluded though, depending on how they represent their managed memory.

Quoted 5 lines

* Tags can be changed only when there are no outstanding pointers to the affected object or region that may be used to access the object or region (i.e., if the object were allocated from the C heap and is it safe to realloc() it, then it is safe to change the tag; for other types of allocation, analogous arguments can be applied).

Tags can only be changed at the point of deallocation/reallocation. Pointers to the object become invalid and cannot be used after it has been deallocated; memory tagging allows to catch such invalid usage.

Quoted 9 lines

* When the kernel dereferences a pointer on userspace's behalf, it shall behave equivalently to userspace dereferencing the same pointer, including use of the same tag (where passed by userspace).

* Where the pointer tag affects pointer dereference behaviour (i.e., with hardware memory colouring) the kernel makes no guarantee to honour pointer tags correctly for every location a buffer based on a pointer passed by userspace to the kernel.

Quoted 7 lines

(This means for example that for a read(fd, buf, size), we can check the tag for a single arbitrary location in *(char (*)[size])buf before passing the buffer to get_user_pages(). Hopefully this could be done in get_user_pages() itself rather than hunting call sites. For userspace, it means that you're on your own if you ask the kernel to operate on a buffer than spans multiple, independently- allocated objects, or a deliberately striped single object.)

I think both points are reasonable. It is very valuable for the kernel to access userspace memory using the user-provided tag, because it enables kernel accesses to be checked in the same way as user accesses, allowing to detect bugs that are potentially hard to find. For instance, if a pointer to an object is passed to the kernel after it has been deallocated, this is invalid and should be detected. However, you are absolutely right that the kernel cannot *guarantee* that such a check is carried out for the entire memory range (or in fact at all); it should be a best-effort approach.

Quoted 6 lines

* The kernel shall not extend the lifetime of user pointers in ways that are not clear from the specification of the syscall or interface to which the pointer is passed (and in any case shall not extend pointer lifetimes without good reason).

Quoted 2 lines

So no clever transparent caching between syscalls, unless it _really_ is transparent in the presence of tags.

Do you have any particular case in mind? If such caching is really valuable, it is always possible to access the object while ignoring the tag. For sure, the user-provided tag can only be used during the syscall handling itself, not asynchronously later on, unless otherwise specified.

Quoted 9 lines

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

Quoted 5 lines

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

This is a disputed point :) In my opinion, this is the the most reasonable approach.

Cheers,
Kevin

Quoted 40 lines

We would need to get some cross-arch buy-in for this, otherwise core maintainers might just refuse to maintain the necessary guarantees.

Quoted 4 lines

Quoted 3 lines

2. Allow tagged addressed passed to memory syscalls (as long as (1) is satisfied). Do I understand correctly that this means that I need to locate all find_vma() callers outside of mm/ and fix them up as well?

Yes (unless anyone as a better idea or objections to this approach).

Also, watch out for code that pokes about inside struct vma directly.

I'm wondering, could we define an explicit type, say,

      struct user_vaddr {
              unsigned long addr;
      };

to replace the unsigned longs in struct vma the mm API? This would turn ad-hoc (unsigned long) casts into build breaks. We could have an explicit conversion functions, say,

      struct user_vaddr __user_vaddr_unsafe(void __user *);
      void __user *__user_ptr_unsafe(struct user_vaddr);

that we robotically insert in all the relevant places to mark unaudited code.

This allows us to keep the kernel buildable, while flagging things that will need review. We would also need to warn the mm folks to reject any new code using these unsafe conversions.

Of course, it would be a non-trivial effort...

Quoted 1 line

BTW, I'll be off until the new year, so won't be able to follow up.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 24 lines · Kevin Brodsky

Quoted 22 lines · Dave Martin

Really, the kernel should do the expected thing with all "non-weird" memory.

In lieu of a proper definition of "non-weird", I think we should have some lists of things that are explicitly included, and also excluded:

OK:
kernel-allocated process stack
brk area
MAP_ANONYMOUS | MAP_PRIVATE
MAP_PRIVATE mappings of /dev/zero

Not OK:
MAP_SHARED
mmaps of non-memory-like devices mmaps of anything that is not a regular file the VDSO
...

In general, userspace can tag memory that it "owns", and we do not assume a transfer of ownership except in the "OK" list above. Otherwise, it's the kernel's memory, or the owner is simply not well defined.

Quoted 11 lines

Agreed on the general idea: a process should be able to pass tagged pointers at the syscall interface, as long as they point to memory privately owned by the process. I think it would be possible to simplify the definition of "non-weird" memory by using only this "OK" list:
- mmap() done by the process itself, where either:
* flags = MAP_PRIVATE | MAP_ANONYMOUS
* flags = MAP_PRIVATE and fd refers to a regular file or a well-defined list of
device files (like /dev/zero)
- brk() done by the process itself
- Any memory mapped by the kernel in the new process's address space during execve(), with the same restrictions as above ([vdso]/[vvar] are therefore excluded)

Quoted 27 lines

Quoted 1 line

* Userspace should set tags at the point of allocation only.

Yes, tags are only supposed to be set at the point of either allocation or deallocation/reallocation. However, allocators can in principle be nested, so an allocator could take a region allocated by malloc() as input and subdivide it (changing tags in the process). That said, this suballocator must not free() that region until all the suballocations themselves have been freed (thereby restoring the tags initially set by malloc()).

Quoted 2 lines

* If you don't know how an object was allocated, you cannot modify the tag, period.

Agreed, allocators that tag memory can only operate on memory with a well-defined provenance (for instance anonymous mmap() or malloc()).

Quoted 2 lines

* A single C object should be accessed using a single, fixed pointer tag throughout its entire lifetime.

Agreed. Allocators themselves may need to be excluded though, depending on how they represent their managed memory.

Quoted 5 lines

* Tags can be changed only when there are no outstanding pointers to the affected object or region that may be used to access the object or region (i.e., if the object were allocated from the C heap and is it safe to realloc() it, then it is safe to change the tag; for other types of allocation, analogous arguments can be applied).

Quoted 3 lines

Tags can only be changed at the point of deallocation/reallocation. Pointers to the object become invalid and cannot be used after it has been deallocated; memory tagging allows to catch such invalid usage.

Quoted 17 lines

Quoted 9 lines

* When the kernel dereferences a pointer on userspace's behalf, it shall behave equivalently to userspace dereferencing the same pointer, including use of the same tag (where passed by userspace).

* Where the pointer tag affects pointer dereference behaviour (i.e., with hardware memory colouring) the kernel makes no guarantee to honour pointer tags correctly for every location a buffer based on a pointer passed by userspace to the kernel.

Quoted 7 lines

(This means for example that for a read(fd, buf, size), we can check the tag for a single arbitrary location in *(char (*)[size])buf before passing the buffer to get_user_pages(). Hopefully this could be done in get_user_pages() itself rather than hunting call sites. For userspace, it means that you're on your own if you ask the kernel to operate on a buffer than spans multiple, independently- allocated objects, or a deliberately striped single object.)

Quoted 8 lines

I think both points are reasonable. It is very valuable for the kernel to access userspace memory using the user-provided tag, because it enables kernel accesses to be checked in the same way as user accesses, allowing to detect bugs that are potentially hard to find. For instance, if a pointer to an object is passed to the kernel after it has been deallocated, this is invalid and should be detected. However, you are absolutely right that the kernel cannot *guarantee* that such a check is carried out for the entire memory range (or in fact at all); it should be a best-effort approach.

It would also be valuable to narrow down the set of "relaxed" (i.e. not tag-checking) syscalls as reasonably possible. We would want to provide tag-checking userspace wrappers for any important calls that are not checked in the kernel. Is it correct to assume that anything that goes through copy_from_user / copy_to_user is checked?

Quoted 8 lines

Quoted 7 lines

* The kernel shall not extend the lifetime of user pointers in ways that are not clear from the specification of the syscall or interface to which the pointer is passed (and in any case shall not extend pointer lifetimes without good reason).

So no clever transparent caching between syscalls, unless it _really_ is transparent in the presence of tags.

Quoted 4 lines

Do you have any particular case in mind? If such caching is really valuable, it is always possible to access the object while ignoring the tag. For sure, the user-provided tag can only be used during the syscall handling itself, not asynchronously later on, unless otherwise specified.

For aio* operations it would be nice if the tag was checked at the time of the actual userspace read/write, either instead of or in addition to at the time of the system call.

Quoted 14 lines

Quoted 13 lines

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

Quoted 1 line

This is a disputed point :) In my opinion, this is the the most reasonable approach.

Yes, it would be nice if the kernel explicitly promised, ex. mprotect() over a range of differently tagged pages to be allowed (i.e. address tag should be unchecked).

Quoted 2 lines · Evgenii Stepanov

Quoted 1 line · Kevin Brodsky

On 19/12/2018 12:52, Dave Martin wrote:

Quoted 12 lines

Quoted 12 lines

Quoted 2 lines

* A single C object should be accessed using a single, fixed pointer tag throughout its entire lifetime.

Agreed. Allocators themselves may need to be excluded though, depending on how they represent their managed memory.

Quoted 5 lines

* Tags can be changed only when there are no outstanding pointers to the affected object or region that may be used to access the object or region (i.e., if the object were allocated from the C heap and is it safe to realloc() it, then it is safe to change the tag; for other types of allocation, analogous arguments can be applied).

Quoted 4 lines

Quoted 4 lines

Tags can only be changed at the point of deallocation/ reallocation. Pointers to the object become invalid and cannot be used after it has been deallocated; memory tagging allows to catch such invalid usage.

All the above sound well but that's mostly a guideline on what a C library can do. It doesn't help much with defining the kernel ABI. Anyway, it's good to clarify the use-cases.

Quoted 5 lines

It would also be valuable to narrow down the set of "relaxed" (i.e. not tag-checking) syscalls as reasonably possible. We would want to provide tag-checking userspace wrappers for any important calls that are not checked in the kernel. Is it correct to assume that anything that goes through copy_from_user / copy_to_user is checked?

I lost track of the context of this thread but if it's just about relaxing the ABI for hwasan, the kernel has no idea of the compiler generated structures in user space, so nothing is checked.

If we talk about tags in the context of MTE, than yes, with the current proposal the tag would be checked by copy_*_user() functions.

Quoted 3 lines

For aio* operations it would be nice if the tag was checked at the time of the actual userspace read/write, either instead of or in addition to at the time of the system call.

With aio* (and synchronous iovec-based syscalls), the kernel may access the memory while the corresponding user process is scheduled out. Given that such access is not done in the context of the user process (and using the user VA like copy_*_user), the kernel cannot handle potential tag faults. Moreover, the transfer may be done by DMA and the device does not understand tags.

I'd like to keep tags as a property of the pointer in a specific virtual address space. The moment you convert it to a different address space (e.g. kernel linear map, physical address), the tag property is stripped and I don't think we should re-build it (and have it checked).

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

Quoted 6 lines

Quoted 2 lines

This is a disputed point :) In my opinion, this is the the most reasonable approach.

Yes, it would be nice if the kernel explicitly promised, ex. mprotect() over a range of differently tagged pages to be allowed (i.e. address tag should be unchecked).

I don't think mprotect() over differently tagged pages was ever a problem. I originally asked that mprotect() and friends do not accept tagged pointers since these functions deal with memory ranges rather than dereferencing such pointer (the reason being minimal kernel changes). However, given how complicated it is to specify an ABI, I came to the conclusion that a pointer passed to such function should be allowed to have non-zero top byte. It would be the kernel's responsibility to strip it out as appropriate.

Quoted 3 lines · Catalin Marinas

Quoted 2 lines · Evgenii Stepanov

Quoted 1 line · Kevin Brodsky

On 19/12/2018 12:52, Dave Martin wrote:

[...]

Quoted 10 lines

Quoted 10 lines

Quoted 10 lines

Quoted 2 lines

* A single C object should be accessed using a single, fixed pointer tag throughout its entire lifetime.

Agreed. Allocators themselves may need to be excluded though, depending on how they represent their managed memory.

Quoted 5 lines

* Tags can be changed only when there are no outstanding pointers to the affected object or region that may be used to access the object or region (i.e., if the object were allocated from the C heap and is it safe to realloc() it, then it is safe to change the tag; for other types of allocation, analogous arguments can be applied).

Quoted 7 lines

Quoted 4 lines

Quoted 4 lines

Tags can only be changed at the point of deallocation/ reallocation. Pointers to the object become invalid and cannot be used after it has been deallocated; memory tagging allows to catch such invalid usage.

All the above sound well but that's mostly a guideline on what a C library can do. It doesn't help much with defining the kernel ABI. Anyway, it's good to clarify the use-cases.

My aim was to clarify the use case in userspace, since I wasn't directly involved in that. The kernel ABI needs to be compatible with the the use case, but doesn't need to specify must of it.

I'm wondering whether we can piggy-back on existing concepts.

We could say that recolouring memory is safe when and only when unmapping of the page or removing permissions on the page (via munmap/mremap/mprotect) would be safe. Otherwise, the resulting behaviour of the process is undefined.

Hopefully there are friendly fuzzers testing this kind of thing.

[...]

Quoted 11 lines

Quoted 5 lines

It would also be valuable to narrow down the set of "relaxed" (i.e. not tag-checking) syscalls as reasonably possible. We would want to provide tag-checking userspace wrappers for any important calls that are not checked in the kernel. Is it correct to assume that anything that goes through copy_from_user / copy_to_user is checked?

I lost track of the context of this thread but if it's just about relaxing the ABI for hwasan, the kernel has no idea of the compiler generated structures in user space, so nothing is checked.

If we talk about tags in the context of MTE, than yes, with the current proposal the tag would be checked by copy_*_user() functions.

Also put_user() and friends?

It might be reasonable to do the check in access_ok() and skip it in __put_user() etc.

(I seem to remember some separate discussion about abolishing __put_user() and friends though, due to the accident risk they pose.)

Quoted 11 lines

Quoted 4 lines

For aio* operations it would be nice if the tag was checked at the time of the actual userspace read/write, either instead of or in addition to at the time of the system call.

With aio* (and synchronous iovec-based syscalls), the kernel may access the memory while the corresponding user process is scheduled out. Given that such access is not done in the context of the user process (and using the user VA like copy_*_user), the kernel cannot handle potential tag faults. Moreover, the transfer may be done by DMA and the device does not understand tags.

Quoted 4 lines

I'd like to keep tags as a property of the pointer in a specific virtual address space. The moment you convert it to a different address space (e.g. kernel linear map, physical address), the tag property is stripped and I don't think we should re-build it (and have it checked).

This is probably reasonable.

Ideally we would check the tag at the point of stripping it off, but most likely it's going to be rather best-effort.

If memory tagging is essential a debugging feature then this seems an acceptable compromise.

Quoted 19 lines

Quoted 14 lines

Quoted 14 lines

Quoted 14 lines

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

Quoted 5 lines

Quoted 2 lines

This is a disputed point :) In my opinion, this is the the most reasonable approach.

Yes, it would be nice if the kernel explicitly promised, ex. mprotect() over a range of differently tagged pages to be allowed (i.e. address tag should be unchecked).

Quoted 8 lines

I don't think mprotect() over differently tagged pages was ever a problem. I originally asked that mprotect() and friends do not accept tagged pointers since these functions deal with memory ranges rather than dereferencing such pointer (the reason being minimal kernel changes). However, given how complicated it is to specify an ABI, I came to the conclusion that a pointer passed to such function should be allowed to have non-zero top byte. It would be the kernel's responsibility to strip it out as appropriate.

I think that if the page range is all the same colour then it should be legitimate to pass a matching tag.

But it doesn't seem reasonable for the kernel to require this. If free() calls munmap(), the page(s) will contain possibly randomly- coloured garbage. There's no correct tag to pass in such a case.

The most obvious solution is just to ignore the tags passed by userspace to such syscalls. This would imply that the kernel must explicitly strip it out, as you suggest.

The number of affected syscalls is relatively small though.

Cheers
---Dave

(+Cc other people with MTE experience: Branislav, Ruben)

Quoted 6 lines

I'm wondering whether we can piggy-back on existing concepts.

We could say that recolouring memory is safe when and only when unmapping of the page or removing permissions on the page (via munmap/mremap/mprotect) would be safe. Otherwise, the resulting behaviour of the process is undefined.

Is that a sufficient requirement? I don't think that anything prevents you from using mprotect() on say [vvar], but we don't necessarily want to map [vvar] as tagged. I'm not sure it's easy to define what "safe" would mean here.

Quoted 5 lines

It might be reasonable to do the check in access_ok() and skip it in __put_user() etc.

(I seem to remember some separate discussion about abolishing __put_user() and friends though, due to the accident risk they pose.)

Keep in mind that with MTE, there is no need to do any explicit check when accessing user memory via a user-provided pointer. The tagged user pointer is directly passed to copy_*_user() or put_user(). If the load/store causes a tag fault, then it is handled just like a page fault (i.e. invoking the fixup handler). As far as I can tell, there's no need to do anything special in access_ok() in that case.

[The above applies to precise mode. In imprecise mode, some more work will be needed after the load/store to check whether a tag fault happened.]

There are many possible ways to deploy MTE, and debugging is just one of them. For instance, you may want to turn on heap colouring for some processes in the system, including in production.

Regarding those cases where it is impossible to check tags at the point of accessing user memory, it is indeed possible to check the memory tags at the point of stripping the tag from the user pointer. Given that some MTE use-cases favour performance over tag check coverage, the ideal approach would be to make these checks configurable (e.g. check one granule, check all of them, or check none). I don't know how feasible this is in practice.

Quoted 1 line · Kevin Brodsky

(+Cc other people with MTE experience: Branislav, Ruben)

[...]

Quoted 11 lines

Quoted 6 lines

I'm wondering whether we can piggy-back on existing concepts.

We could say that recolouring memory is safe when and only when unmapping of the page or removing permissions on the page (via munmap/mremap/mprotect) would be safe. Otherwise, the resulting behaviour of the process is undefined.

Is that a sufficient requirement? I don't think that anything prevents you from using mprotect() on say [vvar], but we don't necessarily want to map [vvar] as tagged. I'm not sure it's easy to define what "safe" would mean here.

I think the origin rules have to apply too: [vvar] is not a regular, private page but a weird, shared thing mapped for you by the kernel.

Presumably userspace _cannot_ do mprotect(PROT_WRITE) on it.

I'm also assuming that userspace cannot recolour memory in read-only pages. That sounds bad if there's no way to prevent it.

[...]

Quoted 13 lines

Quoted 5 lines

It might be reasonable to do the check in access_ok() and skip it in __put_user() etc.

(I seem to remember some separate discussion about abolishing __put_user() and friends though, due to the accident risk they pose.)

Keep in mind that with MTE, there is no need to do any explicit check when accessing user memory via a user-provided pointer. The tagged user pointer is directly passed to copy_*_user() or put_user(). If the load/store causes a tag fault, then it is handled just like a page fault (i.e. invoking the fixup handler). As far as I can tell, there's no need to do anything special in access_ok() in that case.

Quoted 2 lines

[The above applies to precise mode. In imprecise mode, some more work will be needed after the load/store to check whether a tag fault happened.]

Fair enough, I'm a bit hazy on the details as of right now..

[...]

Quoted 3 lines

There are many possible ways to deploy MTE, and debugging is just one of them. For instance, you may want to turn on heap colouring for some processes in the system, including in production.

To implement enforceable protection, or as a diagnostic tool for when something goes wrong?

In the latter case it's still OK for the kernel's tag checking not to be exhaustive.

Quoted 6 lines

Regarding those cases where it is impossible to check tags at the point of accessing user memory, it is indeed possible to check the memory tags at the point of stripping the tag from the user pointer. Given that some MTE use-cases favour performance over tag check coverage, the ideal approach would be to make these checks configurable (e.g. check one granule, check all of them, or check none). I don't know how feasible this is in practice.

Check all granules of a massive DMA buffer?

That doesn't sounds feasible without explicit support in the hardware to have the DMA check tags itself as the memory is accessed. MTE by itself doesn't provide for this IIUC (at least, it would require support in the platform, not just the CPU).

We do not want to bake any assumptions into the ABI about whether a given data transfer may or may not be offloaded to DMA. That feels like a slippery slope.

Providing we get the checks for free in put_user/get_user/ copy_{to,from}_user(), those will cover a lot of cases though, for non-bulk-IO cases.

My assumption has been that at this point in time we are mainly aiming to support the debug/diagnostic use cases today.

At least, those are the low(ish)-hanging fruit.

Others are better placed than me to comment on the goals here.

Cheers
---Dave

Quoted 19 lines · Dave Martin

Quoted 1 line · Kevin Brodsky

(+Cc other people with MTE experience: Branislav, Ruben)

[...]

Quoted 10 lines

Quoted 6 lines

I'm wondering whether we can piggy-back on existing concepts.

We could say that recolouring memory is safe when and only when unmapping of the page or removing permissions on the page (via munmap/mremap/mprotect) would be safe. Otherwise, the resulting behaviour of the process is undefined.

Is that a sufficient requirement? I don't think that anything prevents you from using mprotect() on say [vvar], but we don't necessarily want to map [vvar] as tagged. I'm not sure it's easy to define what "safe" would mean here.

I think the origin rules have to apply too: [vvar] is not a regular, private page but a weird, shared thing mapped for you by the kernel.

Presumably userspace _cannot_ do mprotect(PROT_WRITE) on it.

Quoted 2 lines

I'm also assuming that userspace cannot recolour memory in read-only pages. That sounds bad if there's no way to prevent it.

That sounds like something we would like to do to catch out of bounds read of .rodata globals.
Another potentially interesting use case for MTE is infinite hardware watchpoints - that would require trapping reads for individual tagging granules, include those in read-only binary segment.

Quoted 47 lines

[...]

Quoted 12 lines

Quoted 5 lines

It might be reasonable to do the check in access_ok() and skip it in __put_user() etc.

(I seem to remember some separate discussion about abolishing __put_user() and friends though, due to the accident risk they pose.)

Keep in mind that with MTE, there is no need to do any explicit check when accessing user memory via a user-provided pointer. The tagged user pointer is directly passed to copy_*_user() or put_user(). If the load/store causes a tag fault, then it is handled just like a page fault (i.e. invoking the fixup handler). As far as I can tell, there's no need to do anything special in access_ok() in that case.

Quoted 2 lines

[The above applies to precise mode. In imprecise mode, some more work will be needed after the load/store to check whether a tag fault happened.]

Fair enough, I'm a bit hazy on the details as of right now..

[...]

Quoted 3 lines

There are many possible ways to deploy MTE, and debugging is just one of them. For instance, you may want to turn on heap colouring for some processes in the system, including in production.

To implement enforceable protection, or as a diagnostic tool for when something goes wrong?

In the latter case it's still OK for the kernel's tag checking not to be exhaustive.

Quoted 6 lines

Regarding those cases where it is impossible to check tags at the point of accessing user memory, it is indeed possible to check the memory tags at the point of stripping the tag from the user pointer. Given that some MTE use-cases favour performance over tag check coverage, the ideal approach would be to make these checks configurable (e.g. check one granule, check all of them, or check none). I don't know how feasible this is in practice.

Check all granules of a massive DMA buffer?

That doesn't sounds feasible without explicit support in the hardware to have the DMA check tags itself as the memory is accessed. MTE by itself doesn't provide for this IIUC (at least, it would require support in the platform, not just the CPU).

We do not want to bake any assumptions into the ABI about whether a given data transfer may or may not be offloaded to DMA. That feels like a slippery slope.

Quoted 7 lines

Providing we get the checks for free in put_user/get_user/ copy_{to,from}_user(), those will cover a lot of cases though, for non-bulk-IO cases.

My assumption has been that at this point in time we are mainly aiming to support the debug/diagnostic use cases today.

Quoted 7 lines

At least, those are the low(ish)-hanging fruit.

Others are better placed than me to comment on the goals here.

Cheers
---Dave

Quoted 25 lines · Evgenii Stepanov

Quoted 24 lines · Kevin Brodsky

Quoted 22 lines · Dave Martin

Really, the kernel should do the expected thing with all "non-weird" memory.

In lieu of a proper definition of "non-weird", I think we should have some lists of things that are explicitly included, and also excluded:

OK:
kernel-allocated process stack
brk area
MAP_ANONYMOUS | MAP_PRIVATE
MAP_PRIVATE mappings of /dev/zero

Not OK:
MAP_SHARED
mmaps of non-memory-like devices mmaps of anything that is not a regular file the VDSO
...

In general, userspace can tag memory that it "owns", and we do not assume a transfer of ownership except in the "OK" list above. Otherwise, it's the kernel's memory, or the owner is simply not well defined.

Quoted 11 lines

Quoted 11 lines

Agreed on the general idea: a process should be able to pass tagged pointers at the syscall interface, as long as they point to memory privately owned by the process. I think it would be possible to simplify the definition of "non-weird" memory by using only this "OK" list:
- mmap() done by the process itself, where either:
* flags = MAP_PRIVATE | MAP_ANONYMOUS
* flags = MAP_PRIVATE and fd refers to a regular file or a well-defined list of
device files (like /dev/zero)
- brk() done by the process itself
- Any memory mapped by the kernel in the new process's address space during execve(), with the same restrictions as above ([vdso]/[vvar] are therefore excluded)

Sounds reasonable.

Quoted 26 lines

Quoted 17 lines

Quoted 9 lines

* When the kernel dereferences a pointer on userspace's behalf, it shall behave equivalently to userspace dereferencing the same pointer, including use of the same tag (where passed by userspace).

* Where the pointer tag affects pointer dereference behaviour (i.e., with hardware memory colouring) the kernel makes no guarantee to honour pointer tags correctly for every location a buffer based on a pointer passed by userspace to the kernel.

Quoted 7 lines

(This means for example that for a read(fd, buf, size), we can check the tag for a single arbitrary location in *(char (*)[size])buf before passing the buffer to get_user_pages(). Hopefully this could be done in get_user_pages() itself rather than hunting call sites. For userspace, it means that you're on your own if you ask the kernel to operate on a buffer than spans multiple, independently- allocated objects, or a deliberately striped single object.)

Quoted 8 lines

I think both points are reasonable. It is very valuable for the kernel to access userspace memory using the user-provided tag, because it enables kernel accesses to be checked in the same way as user accesses, allowing to detect bugs that are potentially hard to find. For instance, if a pointer to an object is passed to the kernel after it has been deallocated, this is invalid and should be detected. However, you are absolutely right that the kernel cannot *guarantee* that such a check is carried out for the entire memory range (or in fact at all); it should be a best-effort approach.

Quoted 5 lines

It would also be valuable to narrow down the set of "relaxed" (i.e. not tag-checking) syscalls as reasonably possible. We would want to provide tag-checking userspace wrappers for any important calls that are not checked in the kernel. Is it correct to assume that anything that goes through copy_from_user / copy_to_user is checked?

I lost track of the context of this thread but if it's just about relaxing the ABI for hwasan, the kernel has no idea of the compiler generated structures in user space, so nothing is checked.

If we talk about tags in the context of MTE, than yes, with the current proposal the tag would be checked by copy_*_user() functions.

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

* The kernel shall not extend the lifetime of user pointers in ways that are not clear from the specification of the syscall or interface to which the pointer is passed (and in any case shall not extend pointer lifetimes without good reason).

So no clever transparent caching between syscalls, unless it _really_ is transparent in the presence of tags.

Quoted 8 lines

Quoted 4 lines

Do you have any particular case in mind? If such caching is really valuable, it is always possible to access the object while ignoring the tag. For sure, the user-provided tag can only be used during the syscall handling itself, not asynchronously later on, unless otherwise specified.

For aio* operations it would be nice if the tag was checked at the time of the actual userspace read/write, either instead of or in addition to at the time of the system call.

With aio* (and synchronous iovec-based syscalls), the kernel may access the memory while the corresponding user process is scheduled out. Given that such access is not done in the context of the user process (and using the user VA like copy_*_user), the kernel cannot handle potential tag faults. Moreover, the transfer may be done by DMA and the device does not understand tags.

I'd like to keep tags as a property of the pointer in a specific virtual address space. The moment you convert it to a different address space (e.g. kernel linear map, physical address), the tag property is stripped and I don't think we should re-build it (and have it checked).

Quoted 14 lines

Quoted 14 lines

Quoted 13 lines

* For purposes other than dereference, the kernel shall accept any legitimately tagged pointer (according to the above rules) as identifying the associated memory location.

So, mprotect(some_page_aligned_object, ...); is valid irrespective of where page_aligned_object() came from. There is no implicit derefence by the kernel here, hence no tag check.

The kernel does not guarantee to work correctly if the wrong tag is used, but there is not always a well-defined "right" tag, so we can't really guarantee to check it. So a pointer derived by any reasonable means by userspace has to be treated as equally valid.

Quoted 5 lines

Quoted 1 line

This is a disputed point :) In my opinion, this is the the most reasonable approach.

Yes, it would be nice if the kernel explicitly promised, ex. mprotect() over a range of differently tagged pages to be allowed (i.e. address tag should be unchecked).

I don't think mprotect() over differently tagged pages was ever a problem. I originally asked that mprotect() and friends do not accept tagged pointers since these functions deal with memory ranges rather than dereferencing such pointer (the reason being minimal kernel changes). However, given how complicated it is to specify an ABI, I came to the conclusion that a pointer passed to such function should be allowed to have non-zero top byte. It would be the kernel's responsibility to strip it out as appropriate.

i think these rules work for the cases i care about, a more tricky question is when/how to check for the new syscall abi and when/how the TCR_EL1.TBI0 setting may be turned off.

consider the following cases (tb == top byte):

binary 1: user tb = any, syscall tb = 0
tbi is on, "legacy binary"

binary 2: user tb = any, syscall tb = any
tbi is on, "new binary using tb"
for backward compat it needs to check for new syscall abi.

binary 3: user tb = 0, syscall tb = 0
tbi can be off, "new binary",
binary is marked to indicate unused tb,
kernel may turn tbi off: additional pac bits.

binary 4: user tb = mte, syscall tb = mte
like binary 3, but with mte, "new binary using mte" does it have to check for new syscall abi? or MTE HWCAP would imply it?
(is it possible to use mte without new syscall abi?)

in userspace we want most binaries to be like binary 3 and 4 eventually, i.e. marked as not-relying-on-tbi, if a dso is loaded that is unmarked (legacy or new tb user), then either the load fails (e.g. if mte is already used? or can we turn mte off at runtime?) or tbi has to be enabled (prctl? does this work with pac? or multi-threads?).

as for checking the new syscall abi: i don't see much semantic difference between AT_HWCAP and AT_FLAGS (either way, the user has to check a feature flag before using the feature of the underlying system and it does not matter much if it's a syscall abi feature or cpu feature), but i don't see anything wrong with AT_FLAGS if the kernel prefers that.

the discussion here was mostly about binary 2,

but for
me the open question is if we can make binary 3/4 work. (which requires some elf binary marking, that is recognised by the kernel and dynamic loader, and efficient handling of the TBI0 bit, ..if it's not possible, then i don't see how mte will be deployed).

and i guess on the kernel side the open question is if the rules 1/2/3/4 can be made to work in corner cases e.g. when pointers embedded into structs are passed down in ioctl.

Quoted 3 lines · Szabolcs Nagy

i think these rules work for the cases i care about, a more tricky question is when/how to check for the new syscall abi and when/how the TCR_EL1.TBI0 setting may be turned off.

I don't think turning TBI0 off is critical (it's handy for PAC with 52-bit VA but then it's short-lived if you want more security features like MTE).

Quoted 9 lines

consider the following cases (tb == top byte):

binary 1: user tb = any, syscall tb = 0
tbi is on, "legacy binary"

binary 2: user tb = any, syscall tb = any
tbi is on, "new binary using tb"
for backward compat it needs to check for new syscall abi.

Quoted 7 lines

binary 3: user tb = 0, syscall tb = 0
tbi can be off, "new binary",
binary is marked to indicate unused tb,
kernel may turn tbi off: additional pac bits.

binary 4: user tb = mte, syscall tb = mte
like binary 3, but with mte, "new binary using mte"

Quoted 3 lines

does it have to check for new syscall abi? or MTE HWCAP would imply it?
(is it possible to use mte without new syscall abi?)

I think MTE HWCAP should imply it.

Quoted 6 lines

in userspace we want most binaries to be like binary 3 and 4 eventually, i.e. marked as not-relying-on-tbi, if a dso is loaded that is unmarked (legacy or new tb user), then either the load fails (e.g. if mte is already used? or can we turn mte off at runtime?) or tbi has to be enabled (prctl? does this work with pac? or multi-threads?).

We could enable it via prctl. That's the plan for MTE as well (in addition maybe to some ELF flag).

Quoted 6 lines

as for checking the new syscall abi: i don't see much semantic difference between AT_HWCAP and AT_FLAGS (either way, the user has to check a feature flag before using the feature of the underlying system and it does not matter much if it's a syscall abi feature or cpu feature), but i don't see anything wrong with AT_FLAGS if the kernel prefers that.

The AT_FLAGS is aimed at capturing binary 2 case above, i.e. the relaxation of the syscall ABI to accept tb = any. The MTE support will have its own AT_HWCAP, likely in addition to AT_FLAGS. Arguably, AT_FLAGS is either redundant here if MTE implies it (and no harm in keeping it around) or the meaning is different: a tb != 0 may be checked by the kernel against the allocation tag (i.e. get_user() could fail, the tag is not entirely ignored).

Quoted 1 line

the discussion here was mostly about binary 2,

That's because passing tb != 0 into the syscall ABI is the main blocker here that needs clearing out before merging the MTE support. There is, of course, a variation of binary 1 for MTE:

binary 5: user tb = mte, syscall tb = 0

but this requires a lot of C lib changes to support properly.

Quoted 6 lines

but for
me the open question is if we can make binary 3/4 work. (which requires some elf binary marking, that is recognised by the kernel and dynamic loader, and efficient handling of the TBI0 bit, ..if it's not possible, then i don't see how mte will be deployed).

If we ignore binary 3, we can keep TBI0 = 1 permanently, whether we have MTE or not.

Quoted 3 lines

and i guess on the kernel side the open question is if the rules 1/2/3/4 can be made to work in corner cases e.g. when pointers embedded into structs are passed down in ioctl.

We've been trying to track these down since last summer and we came to the conclusion that it should be (mostly) fine for the non-weird memory described above.

Quoted 7 lines · Catalin Marinas

Quoted 3 lines · Szabolcs Nagy

i think these rules work for the cases i care about, a more tricky question is when/how to check for the new syscall abi and when/how the TCR_EL1.TBI0 setting may be turned off.

I don't think turning TBI0 off is critical (it's handy for PAC with 52-bit VA but then it's short-lived if you want more security features like MTE).

yes, i made a mistake assuming TBI0 off is required for (or at least compatible with) MTE.

if TBI0 needs to be on for MTE then some of my analysis is wrong, and i expect TBI0 to be on in the foreseeable future.

Quoted 9 lines

Quoted 9 lines

consider the following cases (tb == top byte):

binary 1: user tb = any, syscall tb = 0
tbi is on, "legacy binary"

binary 2: user tb = any, syscall tb = any
tbi is on, "new binary using tb"
for backward compat it needs to check for new syscall abi.

Quoted 7 lines

Quoted 7 lines

binary 3: user tb = 0, syscall tb = 0
tbi can be off, "new binary",
binary is marked to indicate unused tb,
kernel may turn tbi off: additional pac bits.

binary 4: user tb = mte, syscall tb = mte
like binary 3, but with mte, "new binary using mte"

so this should be "like binary 2, but with mte".

Quoted 28 lines

Quoted 3 lines

does it have to check for new syscall abi? or MTE HWCAP would imply it?
(is it possible to use mte without new syscall abi?)

I think MTE HWCAP should imply it.

Quoted 6 lines

in userspace we want most binaries to be like binary 3 and 4 eventually, i.e. marked as not-relying-on-tbi, if a dso is loaded that is unmarked (legacy or new tb user), then either the load fails (e.g. if mte is already used? or can we turn mte off at runtime?) or tbi has to be enabled (prctl? does this work with pac? or multi-threads?).

We could enable it via prctl. That's the plan for MTE as well (in addition maybe to some ELF flag).

Quoted 6 lines

as for checking the new syscall abi: i don't see much semantic difference between AT_HWCAP and AT_FLAGS (either way, the user has to check a feature flag before using the feature of the underlying system and it does not matter much if it's a syscall abi feature or cpu feature), but i don't see anything wrong with AT_FLAGS if the kernel prefers that.

The AT_FLAGS is aimed at capturing binary 2 case above, i.e. the relaxation of the syscall ABI to accept tb = any. The MTE support will have its own AT_HWCAP, likely in addition to AT_FLAGS. Arguably, AT_FLAGS is either redundant here if MTE implies it (and no harm in keeping it around) or the meaning is different: a tb != 0 may be checked by the kernel against the allocation tag (i.e. get_user() could fail, the tag is not entirely ignored).

Quoted 8 lines

Quoted 1 line

the discussion here was mostly about binary 2,

That's because passing tb != 0 into the syscall ABI is the main blocker here that needs clearing out before merging the MTE support. There is, of course, a variation of binary 1 for MTE:

binary 5: user tb = mte, syscall tb = 0

but this requires a lot of C lib changes to support properly.

yes, i don't think we want to do that.

but it's ok to have both syscall tbi AT_FLAGS and MTE HWCAP.

Quoted 9 lines

Quoted 6 lines

but for
me the open question is if we can make binary 3/4 work. (which requires some elf binary marking, that is recognised by the kernel and dynamic loader, and efficient handling of the TBI0 bit, ..if it's not possible, then i don't see how mte will be deployed).

If we ignore binary 3, we can keep TBI0 = 1 permanently, whether we have MTE or not.

Quoted 6 lines

Quoted 3 lines

and i guess on the kernel side the open question is if the rules 1/2/3/4 can be made to work in corner cases e.g. when pointers embedded into structs are passed down in ioctl.

We've been trying to track these down since last summer and we came to the conclusion that it should be (mostly) fine for the non-weird memory described above.

i think an interesting case is when userspace passes a pointer to the kernel and later gets it back, which is why i proposed rule 4 (kernel has to keep the tag then).

but i wonder what's the right thing to do for sp (user can malloc thread/sigalt/makecontext stack which will be mte tagged in practice with mte on) does tagged sp work? should userspace untag the stack memory before setting it up as a stack? (but then user pointers to that allocation may get broken..)

arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.

Right now the kernel is already able to handle user faults with tagged pointers, due to these patches:

1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a tagged pointer")
2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged pointers")
3. 276e9327 ("arm64: entry: improve data abort handling of tagged pointers")

When passing tagged pointers to syscalls, there's a special case of such a pointer being passed to one of the memory syscalls (mmap, mprotect, etc.). These syscalls don't do memory accesses but rather deal with memory ranges, hence an untagged pointer is better suited.

This patchset extends tagged pointer support to non-memory syscalls. This is done by reusing the untagged_addr macro to untag user pointers when the kernel performs pointer checking to find out whether the pointer comes from userspace (most notably in access_ok). The untagging is done only when the pointer is being checked, the tag is preserved as the pointer makes its way through the kernel.

One of the alternative approaches to untagging that was considered is to completely strip the pointer tag as the pointer enters the kernel with some kind of a syscall wrapper, but that won't work with the countless number of different ioctl calls. With this approach we would need a custom wrapper for each ioctl variation, which doesn't seem practical.

The following testing approaches has been taken to find potential issues with user pointer untagging:

1. Static testing (with sparse [2] and separately with a custom static analyzer based on Clang) to track casts of __user pointers to integer types to find places where untagging needs to be done.

2. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running a modified syzkaller version that passes tagged pointers to the kernel.

Based on the results of the testing the requried patches have been added to the patchset.

This patchset has been merged into the Pixel 2 kernel tree and is now being used to enable testing of Pixel 2 phones with HWASan.

This patchset is a prerequisite for ARM's memory tagging hardware feature support [3].

Quoted 40 lines · Andrey Konovalov

arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.

Right now the kernel is already able to handle user faults with tagged pointers, due to these patches:

1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a tagged pointer")
2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged pointers")
3. 276e9327 ("arm64: entry: improve data abort handling of tagged pointers")

When passing tagged pointers to syscalls, there's a special case of such a pointer being passed to one of the memory syscalls (mmap, mprotect, etc.). These syscalls don't do memory accesses but rather deal with memory ranges, hence an untagged pointer is better suited.

This patchset extends tagged pointer support to non-memory syscalls. This is done by reusing the untagged_addr macro to untag user pointers when the kernel performs pointer checking to find out whether the pointer comes from userspace (most notably in access_ok). The untagging is done only when the pointer is being checked, the tag is preserved as the pointer makes its way through the kernel.

One of the alternative approaches to untagging that was considered is to completely strip the pointer tag as the pointer enters the kernel with some kind of a syscall wrapper, but that won't work with the countless number of different ioctl calls. With this approach we would need a custom wrapper for each ioctl variation, which doesn't seem practical.

The following testing approaches has been taken to find potential issues with user pointer untagging:

1. Static testing (with sparse [2] and separately with a custom static analyzer based on Clang) to track casts of __user pointers to integer types to find places where untagging needs to be done.

Quoted 8 lines

2. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running a modified syzkaller version that passes tagged pointers to the kernel.

Based on the results of the testing the requried patches have been added to the patchset.

This patchset has been merged into the Pixel 2 kernel tree and is now being used to enable testing of Pixel 2 phones with HWASan.

Do you have an idea of how much of the user/kernel interface is covered by this workload?

Quoted 3 lines

This patchset is a prerequisite for ARM's memory tagging hardware feature support [3].

It looks like there's been a lot of progress made here towards smoking out most of the sites in the kernel where pointers need to be untagged.

However, I do think that we need a clear policy for how existing kernel interfaces are to be interpreted in the presence of tagged pointers. Unless we have that nailed down, we are likely to be able to make only vague guarantees to userspace about what works, and the ongoing risk of ABI regressions and inconsistencies seems high.

I don't really see how we can advertise a full system interface if we know some subset of it doesn't work for foreseeable userspace environments. I feel that presenting the current changes as an ABI relaxation may be a recipe for future problems, since the forwards compatibility guarantees we're able to make today are few and rather vague.

Can we define an opt-in for tagged-pointer userspace, that rejects all syscalls that we haven't checked and whitelisted (or that are uncheckable like ioctl)? This reflects the reality that we don't have a regular userspace environment in which standards-compliant software that uses address tags in a reasonable way will just work.

It might be feasible to promote this to be enabled by default later on, if it becomes sufficiently complete.

In the meantime, I think we really need to nail down the kernel's policies on

* in the default configuration (without opt-in), is the presence of
non-address bits in pointers exchanged with the kernel simply considered broken? (Even with this series, the de factor answer generally seems to be "yes", although many specific things will now work fine)

* if not, how do we tighten syscall / interface specifications to
describe what happens with pointers containing non-address bits, while keeping the existing behaviour for untagged pointers?

We would want a general recipe that gives clear guidance on what userspace should expect an arbitrarily chosen syscall to do with its pointers, without having to enumerate each and every case.

To be sustainable, we would also need to solve that in a way that doesn't need to be reintented per-arch.

There may already be some background on these topics -- can you throw me a link if so?

Cheers
---Dave

Quoted 4 lines · Andrey Konovalov

arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.

It looks like there's been a lot of progress made here towards smoking out most of the sites in the kernel where pointers need to be untagged.

However, I do think that we need a clear policy for how existing kernel interfaces are to be interpreted in the presence of tagged pointers. Unless we have that nailed down, we are likely to be able to make only vague guarantees to userspace about what works, and the ongoing risk of ABI regressions and inconsistencies seems high.

Can we define an opt-in for tagged-pointer userspace, that rejects all syscalls that we haven't checked and whitelisted (or that are uncheckable like ioctl)?

In the meantime, I think we really need to nail down the kernel's policies on

* in the default configuration (without opt-in), is the presence of
non-address bits in pointers exchanged with the kernel simply considered broken? (Even with this series, the de factor answer generally seems to be "yes", although many specific things will now work fine)

* if not, how do we tighten syscall / interface specifications to
describe what happens with pointers containing non-address bits, while keeping the existing behaviour for untagged pointers?

We would want a general recipe that gives clear guidance on what userspace should expect an arbitrarily chosen syscall to do with its pointers, without having to enumerate each and every case.

There may already be some background on these topics -- can you throw me a link if so?

Hi Dave,

Quoted 5 lines · Dave P Martin

Quoted 4 lines · Andrey Konovalov

arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces.

[...]

Quoted 2 lines

It looks like there's been a lot of progress made here towards smoking out most of the sites in the kernel where pointers need to be untagged.

In summary, based on last summer's analysis, there are two main (and rather broad) scenarios of __user pointers use in the kernel: (a) uaccess macros, together with access_ok() checks and (b) identifying of user address ranges (find_vma() and related, some ioctls). The patches here handle the former by allowing sign-extension in access_ok() and subsequent uaccess routines work fine with tagged pointers. Identifying the latter is a bit more problematic and the approach we took was tracking down pointer to long conversion which seems to cover the majority of cases. However, this approach doesn't scale as, for example, we'd rather change get_user_pages() to sign-extend the address rather than all the callers. In lots of other cases we don't even need untagging as we don't expect user space to tag such pointers (i.e. mmap() of device memory).

We might be able to improve the static analysis by introducing a virt_addr_t but that's significant effort and we still won't cover all cases (e.g. it doesn't necessarily catch tcp_zerocopy_receive() which wouldn't use a pointer, just a u64 for address).

Quoted 5 lines

However, I do think that we need a clear policy for how existing kernel interfaces are to be interpreted in the presence of tagged pointers. Unless we have that nailed down, we are likely to be able to make only vague guarantees to userspace about what works, and the ongoing risk of ABI regressions and inconsistencies seems high.

I agree.

Quoted 3 lines

Can we define an opt-in for tagged-pointer userspace, that rejects all syscalls that we haven't checked and whitelisted (or that are uncheckable like ioctl)?

Defining an opt-in is not a problem, however, rejecting all syscalls that we haven't whitelisted is not feasible. We can have an opt-in per process (that's what we were going to do with MTE) but the only thing we can reasonably do is change the behaviour of access_ok(). That's too big a knob and a new syscall that we haven't got around to whitelist may just work. This eventually leads to de-facto ABI and our whitelist would simply be ignored.

I'm not really keen on a big syscall shim in the arm64 kernel which checks syscall arguments, including in-struct values. If we are to do this, I'd rather keep it in user space as part of the C library.

Quoted 8 lines

In the meantime, I think we really need to nail down the kernel's policies on

* in the default configuration (without opt-in), is the presence of
non-address bits in pointers exchanged with the kernel simply considered broken? (Even with this series, the de factor answer generally seems to be "yes", although many specific things will now work fine)

Without these patches, passing non-address bits in pointers is considered broken. I couldn't find a case where it would still work with non-zero tag but maybe I haven't looked hard enough.

Quoted 7 lines

* if not, how do we tighten syscall / interface specifications to
describe what happens with pointers containing non-address bits, while keeping the existing behaviour for untagged pointers?

We would want a general recipe that gives clear guidance on what userspace should expect an arbitrarily chosen syscall to do with its pointers, without having to enumerate each and every case.

That's what we are aiming with the pointer origins, to move away from a syscall whitelist to a generic definition. That said, the two approaches are orthogonal, we can use the pointer origins as the base rule for which syscalls can be whitelisted.

If we step back a bit to look at the use-case for TBI (and MTE), the normal application programmer shouldn't really care about this ABI (well, most of the time). The app gets a tagged pointer from the C library as a result of a malloc()/realloc() (possibly alloca()) call and it expects to be able to pass it back into the kernel (usually via the C library) without any awareness of the non-address bits. Now, we can't define a user/kernel ABI based on the provenance of the pointer in user space (i.e. we only support tags for heap and stack), so we are trying to generalise this based where the pointer originated from in the kernel (e.g. anonymous mmap()).