On Tue, Jun 18, 2019 at 02:13:01PM +0100, Kevin Brodsky wrote:

On 13/06/2019 16:51, Vincenzo Frascino wrote:

quoted

+The ARM64 Tagged Address ABI is an opt-in feature, and an application can
+control it using the following:
+ - /proc/sys/abi/tagged_addr: a new sysctl interface that can be used to
+        prevent the applications from enabling the relaxed ABI.
+        The sysctl is meant also for testing purposes in order to provide a
+        simple way for the userspace to verify the return error checking of
+        the prctl() commands without having to reconfigure the kernel.
+        The sysctl supports the following configuration options:
+         - 0: Disable ARM64 Tagged Address ABI for all the applications.
+         - 1 (Default): Enable ARM64 Tagged Address ABI for all the
+                        applications.

I find this very confusing, because it suggests that the default value of
PR_GET_TAGGED_ADDR_CTRL for new processes will be set to the value of this
sysctl, when in fact this sysctl is about restricting the *availability* of
the new ABI. Instead of disabling the ABI, I would talk about disabling
access to the new ABI here.

This bullet point needs to be re-written. The sysctl is meant to disable
opting in to the ABI. I'd also drop the "meant for testing" part. I put
it in my commit log as justification but I don't think it should be part
of the ABI document.

quoted

+ - prctl()s:
+  - PR_SET_TAGGED_ADDR_CTRL: can be used to enable or disable the Tagged
+        Address ABI.
+        The (unsigned int) arg2 argument is a bit mask describing the
+        control mode used:
+          - PR_TAGGED_ADDR_ENABLE: Enable ARM64 Tagged Address ABI.
+        The arguments arg3, arg4, and arg5 are ignored.

Have we definitely decided that arg{3,4,5} are ignored? Catalin?

I don't have a strong preference either way. If it's simpler for the
user to ignore them, fine by me. I can see in the current prctl commands
a mix if ignore vs forced zero.

quoted

+the ABI guarantees the following behaviours:
+
+  - Every current or newly introduced syscall can accept any valid tagged
+    pointers.

"pointer". Also, is it really useful to talk about newly introduced syscall?
New from which point of view?

I think we should drop this guarantee. It would have made sense if we
allowed tagged pointers everywhere but we already have some exceptions.

quoted

+3. ARM64 Tagged Address ABI Exceptions
+--------------------------------------
+
+The behaviours described in section 2, with particular reference to the
+acceptance by the syscalls of any valid tagged pointer are not applicable
+to the following cases:
+  - mmap() addr parameter.
+  - mremap() new_address parameter.
+  - prctl_set_mm() struct prctl_map fields.
+  - prctl_set_mm_map() struct prctl_map fields.

prctl_set_mm() and prctl_set_mm_map() are internal kernel functions, not
syscall names. IIUC, we don't want to allow any address field settable via
the PR_SET_MM prctl() to be tagged. Catalin, is that correct? I think this
needs rephrasing.

I fully agree. It should talk about PR_SET_MM, PR_SET_MM_MAP,
PR_SET_MM_MAP_SIZE.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel