On Thu, Jun 13, 2019 at 11:15:34AM +0100, Vincenzo Frascino wrote:
Hi Catalin,
On 12/06/2019 16:35, Catalin Marinas wrote:
Hi Vincenzo,
Some minor comments below but it looks fine to me overall. Cc'ing Szabolcs as well since I'd like a view from the libc people.
Thanks for this, I saw Szabolcs comments.
On Wed, Jun 12, 2019 at 03:21:10PM +0100, Vincenzo Frascino wrote:
diff --git a/Documentation/arm64/tagged-address-abi.txt b/Documentation/arm64/tagged-address-abi.txt new file mode 100644 index 000000000000..96e149e2c55c --- /dev/null +++ b/Documentation/arm64/tagged-address-abi.txt
[...]
+Since it is not desirable to relax the ABI to allow tagged user addresses +into the kernel indiscriminately, arm64 provides a new sysctl interface +(/proc/sys/abi/tagged_addr) that is used to prevent the applications from +enabling the relaxed ABI and a new prctl() interface that can be used to +enable or disable 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() +command without having to reconfigure the kernel.
+The ABI properties are inherited by threads of the same application and +fork()'ed children but cleared when a new process is spawn (execve()).
"spawned".
I'd just say "cleared by execve()."
"Spawn" suggests (v)fork+exec to me (at least, what's what "spawn" means on certain other OSes).
I guess you could drop these three paragraphs here and mention the inheritance properties when introducing the prctl() below. You can also mention the global sysctl switch after the prctl() was introduced.
I will move the last two (rewording them) to the _section_ 2, but I would still prefer the Introduction to give an overview of the solution as well.
+2. ARM64 Tagged Address ABI +---------------------------
+From the kernel syscall interface prospective, we define, for the purposes +of this document, a "valid tagged pointer" as a pointer that either it has
"either has" (no 'it') sounds slightly better but I'm not a native English speaker either.
+a zero value set in the top byte or it has a non-zero value, it is in memory +ranges privately owned by a userspace process and it is obtained in one of +the following ways:
- mmap() done by the process itself, where either:
- flags = MAP_PRIVATE | MAP_ANONYMOUS
- flags = MAP_PRIVATE and the file descriptor refers to a regular
file or "/dev/zero"
- a mapping below sbrk(0) done by the process itself
- any memory mapped by the kernel in the process's address space during
- creation and following the restrictions presented above (i.e. data, bss,
- stack).
+The ARM64 Tagged Address ABI is an opt-in feature, and an application can +control it using the following prctl()s:
- PR_SET_TAGGED_ADDR_CTRL: can be used to enable the Tagged Address ABI.
enable or disable (not sure we need the latter but it doesn't heart).
I'd add the arg2 description here as well.
Good point I missed this.
- PR_GET_TAGGED_ADDR_CTRL: can be used to check the status of the Tagged
Address ABI.
For both prctls, you should also document the zeroed arguments up to arg5 (unless we get rid of the enforcement and just ignore them).
Is there a canonical way to detect whether this whole API/ABI is available? (i.e., try to call this prctl / check for an HWCAP bit, etc.)
[...]
Cheers ---Dave