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
