Re: strscpy

Le 05/06/2020 à 19:50, Maxime Villard a écrit :
> Le 04/06/2020 à 01:02, Taylor R Campbell a écrit :
>>> Date: Tue, 2 Jun 2020 20:25:45 +0200
>>> From: Maxime Villard <[email protected]>
>>>
>>> Here is a patch that converts all of the copystr() calls in the kernel to
>>> strkcpy(). One exception is vfs_subr.c where it will be done differently
>>> and isn't included here.
>>>
>>>     https://m00nbsd.net/garbage/libkern/strkcpy.diff
>
> [...]
> 
> Considering that the error checking of strkcpy (or whatever we call it)
> is the same as strlcpy's, you can expect to be able to do 'l'->'k' in a
> mechanical manner in the vast majority of cases.
> 
> As an example, take sys/kern/. The majority of calls to strlcpy do not
> check the return value. So you can do 'l'->'k' automatically. Four files
> have calls that check the return value: sys_module.c, kern_exec.c,
> uipc_domain.c, kern_sysctl.c. In each of these cases, you can do 'l'->'k'
> automatically too, because the error checking is the same.

So what do people think about this?

> This improves the majority of cases, in that we eliminate the unsafe
> strlen behavior of strlcpy, while keeping a code structure that is the
> same. Doing the replacement in all of the kernel would quite certainly
> fix latent bugs similar to the ones I reported several months ago.
> 
> Le 04/06/2020 à 01:40, Robert Elz a écrit :
>> ps: all that said, I am no fan of replacing the unbroken copystr() calls
>> by anything at all, leave all those alone, just replace strlcpy().
> 
> That's something I suggested a few emails ago; we could keep copystr for
> only a small selected set of places, and these would just be the five
> places where the symmetry with copyinstr is appreciated.

And about that too?

Maxime