On Tue, Jun 18, 2019 at 02:13:01PM +0100, Kevin Brodsky wrote:
On 13/06/2019 16:51, Vincenzo Frascino wrote:
+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 asimple way for the userspace to verify the return error checking ofthe 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 theapplications.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.
- 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 thecontrol 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.
+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.
+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.