Re: [PATCH v2] lib/string.c: implement stpcpy

From: "Dávid Bolvanský" <david.bolvansky@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Eli Friedman <efriedma@quicinc.com>,
	stable@vger.kernel.org, Arvind Sankar <nivedita@alum.mit.edu>,
	Joe Perches <joe@perches.com>,
	Sami Tolvanen <samitolvanen@google.com>,
	Vishal Verma <vishal.l.verma@intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"Joel Fernandes (Google)" <joel@joelfernandes.org>,
	Daniel Axtens <dja@axtens.net>, Ingo Molnar <mingo@kernel.org>,
	Yury Norov <yury.norov@gmail.com>,
	Alexandru Ardelean <alexandru.ardelean@analog.com>,
	linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com
Subject: Re: [PATCH v2] lib/string.c: implement stpcpy
Date: Sat, 15 Aug 2020 19:38:52 +0200	[thread overview]
Message-ID: <672236FE-769D-48F0-AAAD-FB9630BB2FA9@gmail.com> (raw)
In-Reply-To: <202008150921.B70721A359@keescook>

Yeah, sprintf calls should be replaced with something safer.

> Dňa 15. 8. 2020 o 18:34 užívateľ Kees Cook <keescook@chromium.org> napísal:
> 
> On Fri, Aug 14, 2020 at 07:09:44PM -0700, Nick Desaulniers wrote:
>> LLVM implemented a recent "libcall optimization" that lowers calls to
>> `sprintf(dest, "%s", str)` where the return value is used to
>> `stpcpy(dest, str) - dest`. This generally avoids the machinery involved
>> in parsing format strings.  Calling `sprintf` with overlapping arguments
>> was clarified in ISO C99 and POSIX.1-2001 to be undefined behavior.
>> 
>> `stpcpy` is just like `strcpy` except it returns the pointer to the new
>> tail of `dest`. This allows you to chain multiple calls to `stpcpy` in
>> one statement.
> 
> O_O What?
> 
> No; this is a _terrible_ API: there is no bounds checking, there are no
> buffer sizes. Anything using the example sprintf() pattern is _already_
> wrong and must be removed from the kernel. (Yes, I realize that the
> kernel is *filled* with this bad assumption that "I'll never write more
> than PAGE_SIZE bytes to this buffer", but that's both theoretically
> wrong ("640k is enough for anybody") and has been known to be wrong in
> practice too (e.g. when suddenly your writing routine is reachable by
> splice(2) and you may not have a PAGE_SIZE buffer).
> 
> But we cannot _add_ another dangerous string API. We're already in a
> terrible mess trying to remove strcpy[1], strlcpy[2], and strncpy[3]. This
> needs to be addressed up by removing the unbounded sprintf() uses. (And
> to do so without introducing bugs related to using snprintf() when
> scnprintf() is expected[4].)
> 
> -Kees
> 
> [1] https://github.com/KSPP/linux/issues/88
> [2] https://github.com/KSPP/linux/issues/89
> [3] https://github.com/KSPP/linux/issues/90
> [4] https://lore.kernel.org/lkml/20200810092100.GA42813@2f5448a72a42/
> 
> -- 
> Kees Cook