linux-hardening - Re: RFC for a new string-copy function, using mixtures of strlcpy and strscpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VeSxzDFVAgah=NXk4vzKCr0qPHHiyinKzS4vO_tvDrMsg@mail.gmail.com>
Date:   Mon, 8 Nov 2021 10:33:54 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Ajay Garg <ajaygargnsit@...il.com>
Cc:     "andy@...nel.org" <andy@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "adobriyan@...il.com" <adobriyan@...il.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: RFC for a new string-copy function, using mixtures of strlcpy and strscpy

On Mon, Nov 8, 2021 at 9:42 AM Ajay Garg <ajaygargnsit@...il.com> wrote:

...

> >> len = [-7]
> >> a = [123456789]
> >
> > My gosh, this is error code that you must check. We do not need more string copy functions.
>
> Hmm, having the additional function would make things a lot easier.
>
> For example, in file fs/kernfs/dir.c, there are methods like
> "kernfs_name_locked", "kernfs_path_from_node_locked" which simply
> consume the return-value without any checks.
>
> All the above functions have a simple motive : copy as much bytes as
> possible in the destination buffer, and then consume/return the number
> of bytes actually copied (minus the null-terminator byte of course).

Nope. Read the comment WRT strscpy().

> If checks are to be put in-place, it would be too much code/churn,
> adding if checks all over the place.

Yep, that's why in some cases where we know that there can't be
overflow the checks are not present. In some cases it's historically
like this, in some cases checks might be useful and so on. But no, we
do not need more chaos in the string functions.

> If, instead we do a simple replace of "strlcpy" with "strlscpy" at
> these places, we would be good to go (while *really* meeting the
> requirements of these clients at the same time).

-- 
With Best Regards,
Andy Shevchenko