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] [day] [month] [year] [list]
Message-ID: <CAHP4M8WnLA0780yN+bpuuCtir+DLJRxe0atAiLbZO0bTGf6J-Q@mail.gmail.com>
Date:   Tue, 9 Nov 2021 00:50:58 +0530
From:   Ajay Garg <ajaygargnsit@...il.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>, andy@...nel.org,
        akpm@...ux-foundation.org, adobriyan@...il.com,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-hardening@...r.kernel.org
Subject: Re: RFC for a new string-copy function, using mixtures of strlcpy and strscpy

Thanks Keen for your time.

>
> For the specific fs/kerfs/dir.c case, I don't see any problems --
> nothing uses the result (cgroup_name() is the only caller of
> kernfs_name() that I see).
>

I am not worried about this single case as per say.

My intention is to make the lives easier for clients in general, who
have the simple motive : to copy as many bytes as possible, and then
consume/propogate the return-value containing number of bytes
*actually* copied, without having to resort to the identical
4-lines-per-check-fix everywhere.

I think you and me agree on the pain-points of using strlcpy/strscpy.

The general consensus is that no new string-functions should be added
as of now, so I guess every client would require 4-lines-per-check-fix
as of now (wherever applicable of course).

Maybe, the RFC for new function could be discussed in the next
opportune moment, which would then be a simple drop-in replacement,
resulting in 1-lines-per-check-fix (wherever applicable of course).


Thanks and Regards,
Ajay

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ