Re: Usage of strncpy in the kernel

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 04.01.2025 um 12:15 schrieb Johnny Billquist:
> The language, or functions, does not solve the problems, or make
> anything safe. The programmer needs to know what he is doing, and he can
> do things wrong in any environment if he don't know.

I object.

In any mature system, I expect that there are time-tested functions for
everyday tasks, and I expect that these functions guide programmers into
using them correctly, as far as possible.

If the system does not provide functions to solve everyday tasks
efficiently, we get exactly the situation we are in right now, in that
the general-purpose always-available functions strncpy and strlcpy are
used to approximately achieve the desired result.

The beauty of copyin/copyout is that there is no way around them. For
the string functions, the situation is different, as the standard C
library and POSIX provide plenty of functions to choose from, but these
are general-purpose and thus may or may not be suited to the task at hand.

> On 2025-01-04 11:14, David Holland wrote:
>> maybe something like
>>
>> strlcpy_tofixed(char *dest, size_t destlen, const char *src);
>> strlcpy_fromfixed(char *dest, size_t destmax, const char *src, size_t srclen);
>>
>> and
>>
>> strlcpy_zerofill(char *dest, const char *src, size_t destmax);

I like these proposals, as their names clearly communicate their
purpose, and when looking at the code during an audit, I can quickly see
that the copying takes place correctly, by looking at only a single
function call. The functions should not be called "strlcpy" though, as
that implies that they perform a strlen(src). Simply calling them
"strcpy" should suffice. The size_t parameters should all be called
"size" instead of "len" or "max".

In the code snippets from my first post to this discussion, I couldn't
locally see that the strings are null-terminated, or whether they are
intended to be null-terminated at all. But I wanted to see this, to gain
confidence that there are no unwanted buffer overflows or other
vulnerabilities.

Roland