raptor 1d ago
Kees Cook

We can remove strncpy() from the Linux kernel finally! I did the last 6 instances, and dropped all the implementations:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=dev/v7.0-rc2/strncpy

Over the last 6 years working on this, there were 362 commits by 70 contributors. The folks with more than 1 commit were:

211 Justin Stitt <[email protected]>
22 Xu Panda <[email protected]>
21 Kees Cook <[email protected]>
17 Thorsten Blum <[email protected]>
12 Arnd Bergmann <[email protected]>
4 Pranav Tyagi <[email protected]>
4 Lee Jones <[email protected]>
2 Steven Rostedt <[email protected]>
2 Sam Ravnborg <[email protected]>
2 Marcelo Moreira <[email protected]>
2 Krzysztof Kozlowski <[email protected]>
2 Kalle Valo <[email protected]>
2 Jaroslav Kysela <[email protected]>
2 Daniel Thompson <[email protected]>
2 Andrew Lunn <[email protected]>

Thank you to all of you! (And especially to Justin Stitt who took on the brunt of the work.)

kernel/git/kees/linux.git - Various feature branches

Mar 24 at 6:31amWeb
Show threadartlog1d ago
@kees

That's very recent, those last commits are less than one hour ago !

To get the juice of it could you quickly give context ?

Why removing strncpy() from kernel is great ?

What are good practices in kernel when dealing with strings ? ie What does replace strncpy in kernel ?
Show threadMagyk1d ago
@artlog
https://github.com/KSPP/linux/issues/90
@kees
Remove all strncpy() uses · Issue #90 · KSPP/linux

The strncpy() function is actively dangerous to use since it may not NUL-terminate the destination string, resulting in potential memory content exposures, unbounded reads, or crashes. Replacing us...

GitHub
Show threadFandaSin1d ago

@artlog @kees

I've been asking same question.
Here what I found in the commit:
--------------------------------------------------------------------------------------------------------
string: Remove strncpy() from the kerneldev/v7.0-rc2/strncpy
strncpy() has been a persistent source of bugs due to its ambiguous
intended usage and frequently counter-intuitive semantics: it may not
NUL-terminate the destination, and it unconditionally zero-pads to the
full length, which isn't always needed. All former callers have been
migrated[1] to:

- strscpy() for NUL-terminated destinations
- strscpy_pad() for NUL-terminated destinations needing zero-padding
- strtomem_pad() for non-NUL-terminated fixed-width fields
- memcpy_and_pad() for bounded copies with explicit padding
- memcpy() for known-length copies

Remove the generic implementation, its declaration, the FORTIFY_SOURCE
wrapper, and associated tests.

Link: https://github.com/KSPP/linux/issues/90 [1]
Signed-off-by: Kees Cook <[email protected]>
--------------------------------------------------------------------------------------------------------

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=dev/v7.0-rc2/strncpy&id=be568570cf71c5db5d6039ac077d90e3767c2fe1

Remove all strncpy() uses · Issue #90 · KSPP/linux

The strncpy() function is actively dangerous to use since it may not NUL-terminate the destination string, resulting in potential memory content exposures, unbounded reads, or crashes. Replacing us...

GitHub
Show threadRay McCarthy1d ago
@kees
Great work, though it should never have been used in the first place.
Show threadConstellationUnion1d ago

@raymaccarthy @kees

it didn't insure destination NULL termination but it allowed something like a session protocol to pad for you .
so in a perfect world if you can call TCP and understand offsets you can just about roll your own sessions.

Show threadjdb1d ago
@kees
Hi, though I have been using linux for decades, I don't know what it means.
Looks like strncopy() had lots of adherence in many place, but can you explain ?
Thank you.
Show threadMatthias Auswöger1d ago
@jdb @kees
deprecated.rst ->
strncpy() did not guarantee NUL-termination of the destination buffer, leading to linear read overflows and other misbehavior. It also unconditionally NUL-padded the destination, which was a needless performance penalty for callers using only NUL-terminated strings. Due to its various behaviors, it was an ambiguous API for determining what an author's true intent was for the copy.
Show threadMatthias Auswöger1d ago
@jdb
The replacements for strncpy() are:
- strscpy() when the destination must be NUL-terminated.
- strscpy_pad() when the destination must be NUL-terminated and
zero-padded (e.g., structs crossing privilege boundaries).
- memtostr() for NUL-terminated destinations from non-NUL-terminated
fixed-width sources (with the `__nonstring` attribute on the source).
- memtostr_pad() for the same, but with zero-padding.
1/2
Show threadMatthias Auswöger1d ago
@jdb
- strtomem() for non-NUL-terminated fixed-width destinations, with
the `__nonstring` attribute on the destination.
- strtomem_pad() for non-NUL-terminated destinations that also need
zero-padding.
- memcpy_and_pad() for bounded copies from potentially unterminated
sources where the destination size is a runtime value.
2/2