linux-kernel - Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes)

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]

Date:   Sun, 21 Aug 2022 23:40:18 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Steve French <smfrench@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        CIFS <linux-cifs@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: strlcpy() notes (was Re: [GIT PULL] smb3 client fixes)

* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> So I despise strlcpy(), but I think strscpy() is kind of broken too.
> For the generic case, it really should have two separate buffer sizes.
> 
>  (2) if you expect the destination buffer contents to be untouched
> past the terminating NUL character, you're simply out of luck
> 
> The strscpy() assumption is that it can arbitrarily write to the
> destination buffer.
> 
> So the best way to think of "strscpy()" is really as a "optimized
> memcpy for strings". That's almost exactly how it acts. It will do a
> memcpy(), but stop when it notices that it has copied a NUL character.

Not to shed-paint this too much, but would it help if the naming reflected 
that property of chunk-size NUL-(over)write a bit better?

- memcpy_str(), memstrcpy(), memscpy(), etc.?

Developers do tend to think differently about operations that are named 
after memcpy(). Here the argument order and semantics are pretty close to 
memcpy() - if the naming is similar, we'd want people to think of it as a 
memcpy(), not a string-copy.

[ Personally I'd prefer memcpy_str(): it's a variant of memcpy() that stops 
  earlier if possible, and does the 'early stop' safely & robustly. ]

Thanks,

	Ingo