add boot partition size

hc

2023-12-11 d2ccde1c8e90d38cee87a1b0309ad2827f3fd30d

 kernel/Documentation/security/keys/request-key.rst
..
..
@@ -15,26 +15,25 @@
15
15
 
16
16
 or::
17
17
 
18
+	struct key *request_key_tag(const struct key_type *type,
19
+				    const char *description,
20
+				    const struct key_tag *domain_tag,
21
+				    const char *callout_info);
22
+
23
+or::
24
+
18
25
 	struct key *request_key_with_auxdata(const struct key_type *type,
19
26
 					     const char *description,
27
+					     const struct key_tag *domain_tag,
20
28
 					     const char *callout_info,
21
29
 					     size_t callout_len,
22
30
 					     void *aux);
23
31
 
24
32
 or::
25
33
 
26
-	struct key *request_key_async(const struct key_type *type,
27
-				      const char *description,
28
-				      const char *callout_info,
29
-				      size_t callout_len);
30
-
31
-or::
32
-
33
-	struct key *request_key_async_with_auxdata(const struct key_type *type,
34
-						   const char *description,
35
-						   const char *callout_info,
36
-					     	   size_t callout_len,
37
-						   void *aux);
34
+	struct key *request_key_rcu(const struct key_type *type,
35
+				    const char *description,
36
+				    const struct key_tag *domain_tag);
38
37
 
39
38
 Or by userspace invoking the request_key system call::
40
39
 
..
..
@@ -48,14 +47,18 @@
48
47
 destroyed.  The kernel interface returns a pointer directly to the key, and
49
48
 it's up to the caller to destroy the key.
50
49
 
51
-The request_key*_with_auxdata() calls are like the in-kernel request_key*()
52
-calls, except that they permit auxiliary data to be passed to the upcaller (the
53
-default is NULL).  This is only useful for those key types that define their
54
-own upcall mechanism rather than using /sbin/request-key.
50
+The request_key_tag() call is like the in-kernel request_key(), except that it
51
+also takes a domain tag that allows keys to be separated by namespace and
52
+killed off as a group.
55
53
 
56
-The two async in-kernel calls may return keys that are still in the process of
57
-being constructed.  The two non-async ones will wait for construction to
58
-complete first.
54
+The request_key_with_auxdata() calls is like the request_key_tag() call, except
55
+that they permit auxiliary data to be passed to the upcaller (the default is
56
+NULL).  This is only useful for those key types that define their own upcall
57
+mechanism rather than using /sbin/request-key.
58
+
59
+The request_key_rcu() call is like the request_key_tag() call, except that it
60
+doesn't check for keys that are under construction and doesn't attempt to
61
+construct missing keys.
59
62
 
60
63
 The userspace interface links the key to a keyring associated with the process
61
64
 to prevent the key from going away, and returns the serial number of the key to
..
..
@@ -132,7 +135,7 @@
132
135
 Rather than instantiating a key, it is possible for the possessor of an
133
136
 authorisation key to negatively instantiate a key that's under construction.
134
137
 This is a short duration placeholder that causes any attempt at re-requesting
135
-the key whilst it exists to fail with error ENOKEY if negated or the specified
138
+the key while it exists to fail with error ENOKEY if negated or the specified
136
139
 error if rejected.
137
140
 
138
141
 This is provided to prevent excessive repeated spawning of /sbin/request-key
..
..
@@ -148,7 +151,7 @@
148
151
 
149
152
 A search of any particular keyring proceeds in the following fashion:
150
153
 
151
-  1) When the key management code searches for a key (keyring_search_aux) it
154
+  1) When the key management code searches for a key (keyring_search_rcu) it
152
155
      firstly calls key_permission(SEARCH) on the keyring it's starting with,
153
156
      if this denies permission, it doesn't search further.
154
157
 
..
..
@@ -166,6 +169,9 @@
166
169
 The process stops immediately a valid key is found with permission granted to
167
170
 use it.  Any error from a previous match attempt is discarded and the key is
168
171
 returned.
172
+
173
+When request_key() is invoked, if CONFIG_KEYS_REQUEST_CACHE=y, a per-task
174
+one-key cache is first checked for a match.
169
175
 
170
176
 When search_process_keyrings() is invoked, it performs the following searches
171
177
 until one succeeds:
..
..
@@ -186,7 +192,9 @@
186
192
       c) The calling process's session keyring is searched.
187
193
 
188
194
 The moment one succeeds, all pending errors are discarded and the found key is
189
-returned.
195
+returned.  If CONFIG_KEYS_REQUEST_CACHE=y, then that key is placed in the
196
+per-task cache, displacing the previous key.  The cache is cleared on exit or
197
+just prior to resumption of userspace.
190
198
 
191
199
 Only if all these fail does the whole thing fail with the highest priority
192
200
 error.  Note that several errors may have come from LSM.