Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: iac594737:Fastmail
Date:   Tue, 20 Jun 2023 20:56:11 -0400
From:   Demi Marie Obenour <demi@invisiblethingslab.com>
To:     Petr Mladek <pmladek@suse.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc:     David Laight <David.Laight@aculab.com>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Hans de Goede <hdegoede@redhat.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Sakari Ailus <sakari.ailus@linux.intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Juergen Gross <jgross@suse.com>,
        Stefano Stabellini <sstabellini@kernel.org>,
        Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
        Lee Jones <lee@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v3 0/4] Make sscanf() stricter
Message-ID: <ZJJKr0xYvcO7P8QY@itl-email>
References: <ZId/IA41c2sJyvE0@itl-email>
 <ZIeHfBf3aB3vUgRM@smile.fi.intel.com>
 <ZIeMyQXU49OcoxY2@itl-email>
 <ec3d7ebe62654e949329785bb32c3822@AcuMS.aculab.com>
 <ZIiMrDxI5Ts0s8fK@itl-email>
 <23df90dd35874fd89c64906e6a6de164@AcuMS.aculab.com>
 <ZIoeVjC6offUywop@itl-email>
 <e354268a4efe48c9a8023a30c7292d12@AcuMS.aculab.com>
 <ZIr0z6u17xogE5+n@smile.fi.intel.com>
 <ZJGq0UTHPdEuIMal@alley>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="/W/EWKP7OFW36OsZ"
Content-Disposition: inline
In-Reply-To: <ZJGq0UTHPdEuIMal@alley>
Precedence: bulk


--/W/EWKP7OFW36OsZ
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Jun 2023 20:56:11 -0400
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Petr Mladek <pmladek@suse.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: David Laight <David.Laight@aculab.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Hans de Goede <hdegoede@redhat.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Juergen Gross <jgross@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
	Lee Jones <lee@kernel.org>, Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: [PATCH v3 0/4] Make sscanf() stricter

On Tue, Jun 20, 2023 at 03:34:09PM +0200, Petr Mladek wrote:
> On Thu 2023-06-15 14:23:59, Andy Shevchenko wrote:
> > On Thu, Jun 15, 2023 at 08:06:46AM +0000, David Laight wrote:
> > > From: Demi Marie Obenour
> > > > Sent: 14 June 2023 21:09
> >=20
> > ...
> >=20
> > > > > What sort of formats and data are being used?
> > > >=20
> > > > Base-10 or base-16 integers, with whitespace never being valid.
> > >=20
> > > In which case sscanf() really isn't what you are looking for.
> > >=20
> > > > > The "%s" format terminates on whitespace.
> > > > > Even stroul() (and friends) will skip leading whitespace.
> > > >=20
> > > > Yes, which is a reason that strto*l() are just broken IMO.
> > >
> > > They are not 'broken', that is what is useful most of the time.
> > > The usual problem is that "020" is treated as octal.
>=20
> I do not know how many users depend on this behavior. But I believe
> that there are such users. And breaking compatibility with userspace
> implementation would make more harm then good in this case.
>=20
> > > > I=E2=80=99m trying to replace their uses in Xen with custom parsing=
 code.
> > >=20
> > > Then write a custom parser :-)
>=20
> Honestly, I dislike any sscanf() modification which have been suggested
> so far:
>=20
>   + %!d is not acceptable because it produces compiler errors
>=20
>   + %d! is not acceptable because "use 64!" is a realistic string.
>     We could not be sure that "<number>!" will never be parsed
>     in kernel.
>=20
>   + %d%[!] produces compiler error either. It is hard to parse by eyes.
>     Also the meaning of such a format would be far from obvious.
>=20
>   + %pj or another %p modifiers would be hard to understand either.
>=20
>     Yes, we have %pe but I think that only few people really use it.
>     And it is kind of self-explanatory because it is typically
>     used together with ERR_PTR() and with variables called
>     "err" or "ret".
>=20
>=20
> > Hmm... Usually we are against zillion implementations of the same with =
zillion
> > bugs hidden (each buggy implementation with its own bugs).
>=20
> I would really like to see the code depending on it. The cover letter
> suggests that there already is a patch with such a custom parser.
> I am sorry if it has already been mentioned. There were so many threads.
>=20
> Sure, we do not want two full featured sscanf() implementations. But a
> wrapper checking for leading whitespace and using kstrto<foo>
> family does not sound too complex.
>=20
> There should always be a good reason to introduce an incompatibility
> between the kernel and the userspace implementation of a commonly
> used API.
>=20
> Best Regards,
> Petr

I strongly believe that overflow should be forbidden by default, but it
turns out that I do not have time to advance this patch further.  My
understanding is that Xen never wants to allow spaces in Xenstore
entries, but that is easy to ensure via an explicit check prior to
calling vsscanf().
--=20
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

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

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

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmSSSq4ACgkQsoi1X/+c
IsEENBAAxKtLt+LIHXO8ZpbY+RkEdtC5atusiIsk2g39Nsf6slNiN8+ayF5vXpkb
39CayIdya0GzbjCjcWO8bCVN4j5+Ek8SKBi01lswttceqTQIb97e5tg759eUXgdQ
3ylVRrG5KCav8aMUGpOZkuiqvhBy3VEr68XvVmpxf1GaLpDycP2cRuoloOdxFVbU
XNrG5iriYGjXt4l1NXK3rNSZgxmJLores9z8Z8bjRGxzotW6bVvx9Da3DwZqJoo9
1Zi2elSUlmalsBvvX5eG+Pzi5niZaK+O6aqnFpSwbwT/yT5zkBNWJGxIzbGiwYU2
W7N4kCEboYDOf/umzIxCuZUPy8Fk/+QxyDgcwIH5/VAYkt1AauilVT3iBl3SMxHY
Wv6x+eOIQAJsXvf6dkVcF5Cq+HTptjAQakbFAO7Xk23AJW0zmGhBudVTqyBG7JCe
x9iB1mQfeS2rx0MkXJUWGsJsy3XnoJvdDt+HwEbSi4+zwhfyx0nSwuaM8Ng3W2Q8
5fCYxdRykIWBqxk0kr8O8Wdd7CORVOTO4s+/zfJh4d074aFIwpor/4TLtjBjJGie
DZ134c7HCmhENkHWDaGdYY0UKxeTiILfrDX1/yhKx+590dQwxQzxiX2ag3XLCmaR
P3KzvLLz8AQelBb2BW2KS295mM3sEwDy4ggOYrLHXpc++JwK74Q=
=2uLn
-----END PGP SIGNATURE-----

--/W/EWKP7OFW36OsZ--