Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Thu, 19 Oct 2023 10:40:02 +0700
From:   Bagas Sanjaya <bagasdotme@gmail.com>
To:     Kees Cook <keescook@chromium.org>,
        Randy Dunlap <rdunlap@infradead.org>
Cc:     James Dutton <james.dutton@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Justin Stitt <justinstitt@google.com>,
        Calvince Otieno <calvncce@gmail.com>,
        Azeem Shaikh <azeemshaikh38@gmail.com>,
        Andy Shevchenko <andy@kernel.org>
Subject: Re: Is strncpy really less secure than strscpy ?
Message-ID: <ZTClEi_X9-SbiPFU@debian.me>
References: <CAAMvbhG40h6pqSf91BurDHQqeoKfP30bwnpvSDRHBN4Hoygqew@mail.gmail.com>
 <ZTCLLinnaqIILXsJ@debian.me>
 <cf6950bc-32c8-459c-a4b1-ca0a291fc2f8@infradead.org>
 <202310181929.BCC265C@keescook>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="cr65md8gz4E8Td9w"
Content-Disposition: inline
In-Reply-To: <202310181929.BCC265C@keescook>
Precedence: bulk


--cr65md8gz4E8Td9w
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 18, 2023 at 07:56:36PM -0700, Kees Cook wrote:
> On Wed, Oct 18, 2023 at 07:27:20PM -0700, Randy Dunlap wrote:
> >=20
> >=20
> > On 10/18/23 18:49, Bagas Sanjaya wrote:
> > > [Disclaimer: I have little to no knowledge of C, so things may be wro=
ng.
> > >  Please correct me if it is the case. Also Cc: recent people who work=
 on
> > >  strscpy() conversion.]
>=20
> Here are the current docs on the deprecated use of strncpy:
> https://docs.kernel.org/process/deprecated.html#strncpy-on-nul-terminated=
-strings
> which could probably be improved.
>=20
> > Also Cc: the STRING maintainers.
> >=20
> > > On Thu, Oct 19, 2023 at 12:22:33AM +0100, James Dutton wrote:
> > >> Is strncpy really less secure than strscpy ?
>=20
> Very. :)
>=20
> > >> If one uses strncpy and thus put a limit on the buffer size during t=
he
> > >> copy, it is safe. There are no writes outside of the buffer.
> > >> If one uses strscpy and thus put a limit on the buffer size during t=
he
> > >> copy, it is safe. There are no writes outside of the buffer.
> > >=20
> > > Well, assuming that the string is NUL-terminated, the end result shou=
ld
> > > be the same.
>=20
> Note the use of "If" in the above sentences. :) This is what makes
> strncpy so dangerous -- it's only "correct" if the length argument is
> less than the size of the _source_ buffer. And by "correct", I mean
> that only then will strncpy produce a C-string. If not, it's a memcpy
> and leaves the buffer unterminated. This lack of %NUL-termination leads
> to all kinds of potential "downstream" problems with reading past the
> end of the buffer, etc.

Oh, that's what I mean by the same results.

>=20
> One of the easiest ways to avoid bugs is to remove ambiguity, and
> strncpy is full of it. :P
>=20
> Almost more important than the potential lack of %NUL-termination is
> the fact that strncpy() doesn't tell other maintainers _why_ it was used
> because it has several "effects" that aren't always intended:
>=20
> - is the destination supposed to be %NUL terminated? (We covered this)
> - is the destination supposed to be %NUL padded?
>=20
> strncpy pads the destination -- is this needed? Is it a waste of CPU
> time?
>=20
> > >=20
> > >> But, one can fit more characters in strncpy than strscpy because
> > >> strscpy enforces the final \0 on the end.
> > >> One could argue that strncpy is better because it might save the spa=
ce
> > >> of one char at the end of a string array.
>=20
> At the cost of creating non-C-strings. And this is a completely bonkers
> result for the "C String API" to produce. :P
>=20
> > >> There are cases where strncpy might be unsafe. For example copying
> > >> between arrays of different sizes, and that is a case where strscpy
> > >> might be safer, but strncpy can be made safe if one ensures that the
> > >> size used in strncpy is the smallest of the two different array size=
s.
>=20
> The CONFIG_FORTIFY_SOURCE option in the kernel adds a bunch of
> sanity-checking to the APIs (some of which can be determined at compile
> time), but it doesn't remove the ambiguity of using strncpy. We want the
> kernel to have maintainable code, and when it's not clear which of a
> handful of side-effects are _intended_ from an API, that's a bad API. :)
>=20
> > >=20
> > > Code example on both cases?
> > >=20
> > >>
> > >> If one blindly replaces strncpy with strscpy across all uses, one
> > >> could unintentionally be truncating the results and introduce new
> > >> bugs.
>=20
> Yes, of course. That's why we're not blindly replacing them. :) And the
> diagnostic criteria has been carefully described:
> https://github.com/KSPP/linux/issues/90
>=20

Thanks for the explanation!

--=20
An old man doll... just what I always wanted! - Clara

--cr65md8gz4E8Td9w
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSSYQ6Cy7oyFNCHrUH2uYlJVVFOowUCZTClDgAKCRD2uYlJVVFO
o7xeAP489Ie/HoB+vWO6ImArSb4o4Vg0dLOeod7/BazTDazfAQEA7pI79ussFSjl
3dGEio/J7sGz7YNEDOwQhJ1JtnLZgwQ=
=0Hki
-----END PGP SIGNATURE-----

--cr65md8gz4E8Td9w--