summaryrefslogtreecommitdiffstats
path: root/man7/pkeys.7
diff options
context:
space:
mode:
Diffstat (limited to 'man7/pkeys.7')
-rw-r--r--man7/pkeys.734
1 files changed, 17 insertions, 17 deletions
diff --git a/man7/pkeys.7 b/man7/pkeys.7
index 4fb814c99..1ef0c557d 100644
--- a/man7/pkeys.7
+++ b/man7/pkeys.7
@@ -27,9 +27,9 @@ Protection keys work in conjunction with the existing
and
.B PROT_EXEC
permissions passed to system calls such as
-.BR mprotect (2)
+.MR mprotect 2
and
-.BR mmap (2),
+.MR mmap 2 ,
but always act to further restrict these traditional permission
mechanisms.
.P
@@ -38,7 +38,7 @@ restrictions, it receives a
.B SIGSEGV
signal.
See
-.BR sigaction (2)
+.MR sigaction 2
for details of the information available with that signal.
.P
To use the pkeys feature, the processor must support it, and the kernel
@@ -49,7 +49,7 @@ However, pkey 0 is used as the default key, so a maximum of 15
are available for actual application use.
The default key is assigned to any memory region for which a
pkey has not been explicitly assigned via
-.BR pkey_mprotect (2).
+.MR pkey_mprotect 2 .
.P
Protection keys have the potential to add a layer of security and
reliability to applications.
@@ -62,13 +62,13 @@ the PKRU register or can execute arbitrary instructions.
Applications should be very careful to ensure that they do not "leak"
protection keys.
For instance, before calling
-.BR pkey_free (2),
+.MR pkey_free 2 ,
the application should be sure that no memory has that pkey assigned.
If the application left the freed pkey assigned, a future user of
that pkey might inadvertently change the permissions of an unrelated
data structure, which could impact security or stability.
The kernel currently allows in-use pkeys to have
-.BR pkey_free (2)
+.MR pkey_free 2
called on them because it would have processor or memory performance
implications to perform the additional checks needed to disallow it.
Implementation of the necessary checks is left up to applications.
@@ -76,7 +76,7 @@ Applications may implement these checks by searching the
.IR /proc/ pid /smaps
file for memory regions with the pkey assigned.
Further details can be found in
-.BR proc (5).
+.MR proc 5 .
.P
Any application wanting to use protection keys needs to be able
to function without them.
@@ -87,7 +87,7 @@ because the keys have all been allocated, perhaps by a library
the application is using.
It is recommended that applications wanting to use protection
keys should simply call
-.BR pkey_alloc (2)
+.MR pkey_alloc 2
and test whether the call succeeds,
instead of attempting to detect support for the
feature in any other way.
@@ -109,11 +109,11 @@ Applications using threads and protection keys should be especially
careful.
Threads inherit the protection key rights of the parent at the time
of the
-.BR clone (2),
+.MR clone 2 ,
system call.
Applications should either ensure that their own permissions are
appropriate for child threads at the time when
-.BR clone (2)
+.MR clone 2
is called, or ensure that each child thread can perform its
own initialization of protection key rights.
.\"
@@ -134,10 +134,10 @@ The signal behavior is the same as that of floating-point registers.
.\"
.SS Protection Keys system calls
The Linux kernel implements the following pkey-related system calls:
-.BR pkey_mprotect (2),
-.BR pkey_alloc (2),
+.MR pkey_mprotect 2 ,
+.MR pkey_alloc 2 ,
and
-.BR pkey_free (2).
+.MR pkey_free 2 .
.P
The Linux pkey system calls are available only if the kernel was
configured and built with the
@@ -231,7 +231,7 @@ main(void)
}
.EE
.SH SEE ALSO
-.BR pkey_alloc (2),
-.BR pkey_free (2),
-.BR pkey_mprotect (2),
-.BR sigaction (2)
+.MR pkey_alloc 2 ,
+.MR pkey_free 2 ,
+.MR pkey_mprotect 2 ,
+.MR sigaction 2