summaryrefslogtreecommitdiff
path: root/Documentation/security
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/security')
-rw-r--r--Documentation/security/credentials.rst8
-rw-r--r--Documentation/security/keys/request-key.rst2
-rw-r--r--Documentation/security/keys/trusted-encrypted.rst6
3 files changed, 10 insertions, 6 deletions
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index 5bb7125faeee..282e79feee6a 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -291,7 +291,7 @@ for example), it must be considered immutable, barring two exceptions:
1. The reference count may be altered.
- 2. Whilst the keyring subscriptions of a set of credentials may not be
+ 2. While the keyring subscriptions of a set of credentials may not be
changed, the keyrings subscribed to may have their contents altered.
To catch accidental credential alteration at compile time, struct task_struct
@@ -358,7 +358,7 @@ Once a reference has been obtained, it must be released with ``put_cred()``,
Accessing Another Task's Credentials
------------------------------------
-Whilst a task may access its own credentials without the need for locking, the
+While a task may access its own credentials without the need for locking, the
same is not true of a task wanting to access another task's credentials. It
must use the RCU read lock and ``rcu_dereference()``.
@@ -382,7 +382,7 @@ This should be used inside the RCU read lock, as in the following example::
}
Should it be necessary to hold another task's credentials for a long period of
-time, and possibly to sleep whilst doing so, then the caller should get a
+time, and possibly to sleep while doing so, then the caller should get a
reference on them using::
const struct cred *get_task_cred(struct task_struct *task);
@@ -442,7 +442,7 @@ duplicate of the current process's credentials, returning with the mutex still
held if successful. It returns NULL if not successful (out of memory).
The mutex prevents ``ptrace()`` from altering the ptrace state of a process
-whilst security checks on credentials construction and changing is taking place
+while security checks on credentials construction and changing is taking place
as the ptrace state may alter the outcome, particularly in the case of
``execve()``.
diff --git a/Documentation/security/keys/request-key.rst b/Documentation/security/keys/request-key.rst
index 21e27238cec6..600ad67d1707 100644
--- a/Documentation/security/keys/request-key.rst
+++ b/Documentation/security/keys/request-key.rst
@@ -132,7 +132,7 @@ Negative Instantiation And Rejection
Rather than instantiating a key, it is possible for the possessor of an
authorisation key to negatively instantiate a key that's under construction.
This is a short duration placeholder that causes any attempt at re-requesting
-the key whilst it exists to fail with error ENOKEY if negated or the specified
+the key while it exists to fail with error ENOKEY if negated or the specified
error if rejected.
This is provided to prevent excessive repeated spawning of /sbin/request-key
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 6ec6bb2ac497..7b35fcb58933 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -101,7 +101,7 @@ Usage::
Where::
- format:= 'default | ecryptfs'
+ format:= 'default | ecryptfs | enc32'
key-type:= 'trusted' | 'user'
@@ -202,3 +202,7 @@ are anticipated. In particular the new format 'ecryptfs' has been defined in
in order to use encrypted keys to mount an eCryptfs filesystem. More details
about the usage can be found in the file
``Documentation/security/keys/ecryptfs.rst``.
+
+Another new format 'enc32' has been defined in order to support encrypted keys
+with payload size of 32 bytes. This will initially be used for nvdimm security
+but may expand to other usages that require 32 bytes payload.