]>
Commit | Line | Data |
---|---|---|
84253c8b KC |
1 | .. SPDX-License-Identifier: GPL-2.0 |
2 | ||
98348577 FV |
3 | .. _deprecated: |
4 | ||
84253c8b KC |
5 | ===================================================================== |
6 | Deprecated Interfaces, Language Features, Attributes, and Conventions | |
7 | ===================================================================== | |
8 | ||
9 | In a perfect world, it would be possible to convert all instances of | |
10 | some deprecated API into the new API and entirely remove the old API in | |
11 | a single development cycle. However, due to the size of the kernel, the | |
12 | maintainership hierarchy, and timing, it's not always feasible to do these | |
13 | kinds of conversions at once. This means that new instances may sneak into | |
14 | the kernel while old ones are being removed, only making the amount of | |
15 | work to remove the API grow. In order to educate developers about what | |
16 | has been deprecated and why, this list has been created as a place to | |
17 | point when uses of deprecated things are proposed for inclusion in the | |
18 | kernel. | |
19 | ||
20 | __deprecated | |
21 | ------------ | |
22 | While this attribute does visually mark an interface as deprecated, | |
23 | it `does not produce warnings during builds any more | |
24 | <https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_ | |
25 | because one of the standing goals of the kernel is to build without | |
26 | warnings and no one was actually doing anything to remove these deprecated | |
27 | interfaces. While using `__deprecated` is nice to note an old API in | |
28 | a header file, it isn't the full solution. Such interfaces must either | |
29 | be fully removed from the kernel, or added to this file to discourage | |
30 | others from using them in the future. | |
31 | ||
7af51678 KC |
32 | BUG() and BUG_ON() |
33 | ------------------ | |
34 | Use WARN() and WARN_ON() instead, and handle the "impossible" | |
35 | error condition as gracefully as possible. While the BUG()-family | |
36 | of APIs were originally designed to act as an "impossible situation" | |
37 | assert and to kill a kernel thread "safely", they turn out to just be | |
38 | too risky. (e.g. "In what order do locks need to be released? Have | |
39 | various states been restored?") Very commonly, using BUG() will | |
40 | destabilize a system or entirely break it, which makes it impossible | |
41 | to debug or even get viable crash reports. Linus has `very strong | |
42 | <https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/>`_ | |
43 | feelings `about this | |
44 | <https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/>`_. | |
45 | ||
46 | Note that the WARN()-family should only be used for "expected to | |
47 | be unreachable" situations. If you want to warn about "reachable | |
48 | but undesirable" situations, please use the pr_warn()-family of | |
49 | functions. System owners may have set the *panic_on_warn* sysctl, | |
50 | to make sure their systems do not continue running in the face of | |
51 | "unreachable" conditions. (For example, see commits like `this one | |
52 | <https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_.) | |
53 | ||
84253c8b KC |
54 | open-coded arithmetic in allocator arguments |
55 | -------------------------------------------- | |
56 | Dynamic size calculations (especially multiplication) should not be | |
57 | performed in memory allocator (or similar) function arguments due to the | |
58 | risk of them overflowing. This could lead to values wrapping around and a | |
59 | smaller allocation being made than the caller was expecting. Using those | |
60 | allocations could lead to linear overflows of heap memory and other | |
61 | misbehaviors. (One exception to this is literal values where the compiler | |
62 | can warn if they might overflow. Though using literals for arguments as | |
63 | suggested below is also harmless.) | |
64 | ||
65 | For example, do not use ``count * size`` as an argument, as in:: | |
66 | ||
67 | foo = kmalloc(count * size, GFP_KERNEL); | |
68 | ||
69 | Instead, the 2-factor form of the allocator should be used:: | |
70 | ||
71 | foo = kmalloc_array(count, size, GFP_KERNEL); | |
72 | ||
73 | If no 2-factor form is available, the saturate-on-overflow helpers should | |
74 | be used:: | |
75 | ||
76 | bar = vmalloc(array_size(count, size)); | |
77 | ||
78 | Another common case to avoid is calculating the size of a structure with | |
79 | a trailing array of others structures, as in:: | |
80 | ||
81 | header = kzalloc(sizeof(*header) + count * sizeof(*header->item), | |
82 | GFP_KERNEL); | |
83 | ||
84 | Instead, use the helper:: | |
85 | ||
86 | header = kzalloc(struct_size(header, item, count), GFP_KERNEL); | |
87 | ||
68e4cd17 GS |
88 | .. note:: If you are using struct_size() on a structure containing a zero-length |
89 | or a one-element array as a trailing array member, please refactor such | |
90 | array usage and switch to a `flexible array member | |
91 | <#zero-length-and-one-element-arrays>`_ instead. | |
92 | ||
7929b983 JC |
93 | See array_size(), array3_size(), and struct_size(), |
94 | for more details as well as the related check_add_overflow() and | |
95 | check_mul_overflow() family of functions. | |
84253c8b KC |
96 | |
97 | simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() | |
98 | ---------------------------------------------------------------------- | |
7929b983 JC |
99 | The simple_strtol(), simple_strtoll(), |
100 | simple_strtoul(), and simple_strtoull() functions | |
84253c8b | 101 | explicitly ignore overflows, which may lead to unexpected results |
7929b983 JC |
102 | in callers. The respective kstrtol(), kstrtoll(), |
103 | kstrtoul(), and kstrtoull() functions tend to be the | |
84253c8b KC |
104 | correct replacements, though note that those require the string to be |
105 | NUL or newline terminated. | |
106 | ||
107 | strcpy() | |
108 | -------- | |
7929b983 | 109 | strcpy() performs no bounds checking on the destination |
84253c8b KC |
110 | buffer. This could result in linear overflows beyond the |
111 | end of the buffer, leading to all kinds of misbehaviors. While | |
112 | `CONFIG_FORTIFY_SOURCE=y` and various compiler flags help reduce the | |
113 | risk of using this function, there is no good reason to add new uses of | |
7929b983 | 114 | this function. The safe replacement is strscpy(). |
84253c8b KC |
115 | |
116 | strncpy() on NUL-terminated strings | |
117 | ----------------------------------- | |
7929b983 | 118 | Use of strncpy() does not guarantee that the destination buffer |
84253c8b KC |
119 | will be NUL terminated. This can lead to various linear read overflows |
120 | and other misbehavior due to the missing termination. It also NUL-pads the | |
121 | destination buffer if the source contents are shorter than the destination | |
122 | buffer size, which may be a needless performance penalty for callers using | |
7929b983 JC |
123 | only NUL-terminated strings. The safe replacement is strscpy(). |
124 | (Users of strscpy() still needing NUL-padding should instead | |
76136e02 | 125 | use strscpy_pad().) |
84253c8b | 126 | |
053f8fc7 | 127 | If a caller is using non-NUL-terminated strings, strncpy() can |
84253c8b KC |
128 | still be used, but destinations should be marked with the `__nonstring |
129 | <https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ | |
130 | attribute to avoid future compiler warnings. | |
131 | ||
132 | strlcpy() | |
133 | --------- | |
7929b983 | 134 | strlcpy() reads the entire source buffer first, possibly exceeding |
84253c8b KC |
135 | the given limit of bytes to copy. This is inefficient and can lead to |
136 | linear read overflows if a source string is not NUL-terminated. The | |
7929b983 | 137 | safe replacement is strscpy(). |
84253c8b | 138 | |
d8401f50 KC |
139 | %p format specifier |
140 | ------------------- | |
141 | Traditionally, using "%p" in format strings would lead to regular address | |
142 | exposure flaws in dmesg, proc, sysfs, etc. Instead of leaving these to | |
143 | be exploitable, all "%p" uses in the kernel are being printed as a hashed | |
144 | value, rendering them unusable for addressing. New uses of "%p" should not | |
145 | be added to the kernel. For text addresses, using "%pS" is likely better, | |
146 | as it produces the more useful symbol name instead. For nearly everything | |
147 | else, just do not add "%p" at all. | |
148 | ||
149 | Paraphrasing Linus's current `guidance <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_: | |
150 | ||
151 | - If the hashed "%p" value is pointless, ask yourself whether the pointer | |
152 | itself is important. Maybe it should be removed entirely? | |
153 | - If you really think the true pointer value is important, why is some | |
154 | system state or user privilege level considered "special"? If you think | |
155 | you can justify it (in comments and commit log) well enough to stand | |
156 | up to Linus's scrutiny, maybe you can use "%px", along with making sure | |
157 | you have sensible permissions. | |
158 | ||
159 | And finally, know that a toggle for "%p" hashing will `not be accepted <https://lore.kernel.org/lkml/CA+55aFwieC1-nAs+NFq9RTwaR8ef9hWa4MjNBWL41F-8wM49eA@mail.gmail.com/>`_. | |
160 | ||
84253c8b KC |
161 | Variable Length Arrays (VLAs) |
162 | ----------------------------- | |
163 | Using stack VLAs produces much worse machine code than statically | |
164 | sized stack arrays. While these non-trivial `performance issues | |
165 | <https://git.kernel.org/linus/02361bc77888>`_ are reason enough to | |
166 | eliminate VLAs, they are also a security risk. Dynamic growth of a stack | |
167 | array may exceed the remaining memory in the stack segment. This could | |
168 | lead to a crash, possible overwriting sensitive contents at the end of the | |
169 | stack (when built without `CONFIG_THREAD_INFO_IN_TASK=y`), or overwriting | |
170 | memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`) | |
a035d552 GS |
171 | |
172 | Implicit switch case fall-through | |
173 | --------------------------------- | |
76136e02 KC |
174 | The C language allows switch cases to fall through to the next case |
175 | when a "break" statement is missing at the end of a case. This, however, | |
176 | introduces ambiguity in the code, as it's not always clear if the missing | |
177 | break is intentional or a bug. For example, it's not obvious just from | |
178 | looking at the code if `STATE_ONE` is intentionally designed to fall | |
179 | through into `STATE_TWO`:: | |
180 | ||
181 | switch (value) { | |
182 | case STATE_ONE: | |
183 | do_something(); | |
184 | case STATE_TWO: | |
185 | do_other(); | |
186 | break; | |
187 | default: | |
188 | WARN("unknown state"); | |
189 | } | |
b9918bdc JP |
190 | |
191 | As there have been a long list of flaws `due to missing "break" statements | |
a035d552 | 192 | <https://cwe.mitre.org/data/definitions/484.html>`_, we no longer allow |
76136e02 KC |
193 | implicit fall-through. In order to identify intentional fall-through |
194 | cases, we have adopted a pseudo-keyword macro "fallthrough" which | |
195 | expands to gcc's extension `__attribute__((__fallthrough__)) | |
196 | <https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_. | |
197 | (When the C17/C18 `[[fallthrough]]` syntax is more commonly supported by | |
b9918bdc | 198 | C compilers, static analyzers, and IDEs, we can switch to using that syntax |
76136e02 | 199 | for the macro pseudo-keyword.) |
b9918bdc JP |
200 | |
201 | All switch/case blocks must end in one of: | |
202 | ||
76136e02 KC |
203 | * break; |
204 | * fallthrough; | |
205 | * continue; | |
206 | * goto <label>; | |
207 | * return [expression]; | |
68e4cd17 GS |
208 | |
209 | Zero-length and one-element arrays | |
210 | ---------------------------------- | |
211 | There is a regular need in the kernel to provide a way to declare having | |
212 | a dynamically sized set of trailing elements in a structure. Kernel code | |
213 | should always use `"flexible array members" <https://en.wikipedia.org/wiki/Flexible_array_member>`_ | |
214 | for these cases. The older style of one-element or zero-length arrays should | |
215 | no longer be used. | |
216 | ||
217 | In older C code, dynamically sized trailing elements were done by specifying | |
218 | a one-element array at the end of a structure:: | |
219 | ||
220 | struct something { | |
221 | size_t count; | |
222 | struct foo items[1]; | |
223 | }; | |
224 | ||
225 | This led to fragile size calculations via sizeof() (which would need to | |
226 | remove the size of the single trailing element to get a correct size of | |
227 | the "header"). A `GNU C extension <https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_ | |
228 | was introduced to allow for zero-length arrays, to avoid these kinds of | |
229 | size problems:: | |
230 | ||
231 | struct something { | |
232 | size_t count; | |
233 | struct foo items[0]; | |
234 | }; | |
235 | ||
236 | But this led to other problems, and didn't solve some problems shared by | |
237 | both styles, like not being able to detect when such an array is accidentally | |
238 | being used _not_ at the end of a structure (which could happen directly, or | |
239 | when such a struct was in unions, structs of structs, etc). | |
240 | ||
241 | C99 introduced "flexible array members", which lacks a numeric size for | |
242 | the array declaration entirely:: | |
243 | ||
244 | struct something { | |
245 | size_t count; | |
246 | struct foo items[]; | |
247 | }; | |
248 | ||
249 | This is the way the kernel expects dynamically sized trailing elements | |
250 | to be declared. It allows the compiler to generate errors when the | |
251 | flexible array does not occur last in the structure, which helps to prevent | |
252 | some kind of `undefined behavior | |
253 | <https://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf>`_ | |
254 | bugs from being inadvertently introduced to the codebase. It also allows | |
255 | the compiler to correctly analyze array sizes (via sizeof(), | |
256 | `CONFIG_FORTIFY_SOURCE`, and `CONFIG_UBSAN_BOUNDS`). For instance, | |
257 | there is no mechanism that warns us that the following application of the | |
258 | sizeof() operator to a zero-length array always results in zero:: | |
259 | ||
260 | struct something { | |
261 | size_t count; | |
262 | struct foo items[0]; | |
263 | }; | |
264 | ||
265 | struct something *instance; | |
266 | ||
267 | instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); | |
268 | instance->count = count; | |
269 | ||
270 | size = sizeof(instance->items) * instance->count; | |
271 | memcpy(instance->items, source, size); | |
272 | ||
273 | At the last line of code above, ``size`` turns out to be ``zero``, when one might | |
274 | have thought it represents the total size in bytes of the dynamic memory recently | |
275 | allocated for the trailing array ``items``. Here are a couple examples of this | |
276 | issue: `link 1 | |
277 | <https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_, | |
278 | `link 2 | |
279 | <https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf>`_. | |
280 | Instead, `flexible array members have incomplete type, and so the sizeof() | |
281 | operator may not be applied <https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, | |
282 | so any misuse of such operators will be immediately noticed at build time. | |
283 | ||
284 | With respect to one-element arrays, one has to be acutely aware that `such arrays | |
285 | occupy at least as much space as a single object of the type | |
286 | <https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, | |
287 | hence they contribute to the size of the enclosing structure. This is prone | |
288 | to error every time people want to calculate the total size of dynamic memory | |
289 | to allocate for a structure containing an array of this kind as a member:: | |
290 | ||
291 | struct something { | |
292 | size_t count; | |
293 | struct foo items[1]; | |
294 | }; | |
295 | ||
296 | struct something *instance; | |
297 | ||
298 | instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL); | |
299 | instance->count = count; | |
300 | ||
301 | size = sizeof(instance->items) * instance->count; | |
302 | memcpy(instance->items, source, size); | |
303 | ||
304 | In the example above, we had to remember to calculate ``count - 1`` when using | |
305 | the struct_size() helper, otherwise we would have --unintentionally-- allocated | |
306 | memory for one too many ``items`` objects. The cleanest and least error-prone way | |
307 | to implement this is through the use of a `flexible array member`:: | |
308 | ||
309 | struct something { | |
310 | size_t count; | |
311 | struct foo items[]; | |
312 | }; | |
313 | ||
314 | struct something *instance; | |
315 | ||
316 | instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); | |
317 | instance->count = count; | |
318 | ||
319 | size = sizeof(instance->items[0]) * instance->count; | |
320 | memcpy(instance->items, source, size); |