From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D07AAC83F09 for ; Tue, 8 Jul 2025 16:14:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65E6D6B00A3; Tue, 8 Jul 2025 12:14:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60ED56B00A4; Tue, 8 Jul 2025 12:14:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4FE4B6B00A5; Tue, 8 Jul 2025 12:14:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3B2A76B00A3 for ; Tue, 8 Jul 2025 12:14:29 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 11ED61406A6 for ; Tue, 8 Jul 2025 16:14:29 +0000 (UTC) X-FDA: 83641595058.17.0A9829B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id 50EDDC0006 for ; Tue, 8 Jul 2025 16:14:27 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q48En5Xx; spf=pass (imf28.hostedemail.com: domain of alx@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=alx@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751991267; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LWFZZbbE5Kesn1qqHv/z8/iOC50rgh4eT/OcY8Gk3pw=; b=f8i5nUxEZaGiIIj6pKBCofJ7oaZ2mNpU04xXAhzxM9JT98i5SsmMW0lHa641lrhUQfE1pk 8Gvqr0iPCWUgf3e2UNuT090X+xsZpSDfN+j6l61Jl/S02kBjy1mVJIM9pynqMaFlKmrLjN fq/VcWB9AZ2fqZ31sdug8W1/N98GWf0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751991267; a=rsa-sha256; cv=none; b=Yl130VgmS8OqzqBBpAzEO2nV/j1vC80AuK2I/XDxLFha+9nx0xpbHsIos/18252IFqOi4T EC7YG4inhdOFkvuhQXWsTcEE4ntogJAZrFf4YMtP7KT5zTZqnK5q7FEoTR05IUfgJ6Y4eM DP9xT9iox/2ycqU7he+XknJ7QiGp0IQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q48En5Xx; spf=pass (imf28.hostedemail.com: domain of alx@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=alx@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 72DFF5C58DA; Tue, 8 Jul 2025 16:14:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4ED1C4CEED; Tue, 8 Jul 2025 16:14:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751991266; bh=9VJ1nAIku89khtvQrVlc23Y/ORI9Fv5eKjw3C6IpwGc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Q48En5XxhxAXTUKM8v+dgVwYZ7UEEkh8gDOJHzjAw07He9s6U4Gy1G8wyS2VeF5IL e6Pc0kVolCufQz4buTOCAwcdkRLWrKVhrAOlnAlrRjh1Ao9KLuLBiio1hgTEygHetO TdRKVlHU6j6DeTWcXlJPKj8KzMPHCxLULlYL+DJDWjkKWGlhAgu3OlLmOBJGyXMe/S Khou6QGPq/vKenLJI0vPZ84XFLx53flf4NGBBtHolBEa9drGlbvycXU0gmHgV9Bz1F NljBr7BpiKC2xqt7WideBwOprEhtQ1p/PbwGrG6hC42BzKGb6mnrCHg0p+jUcS11OZ TAJY3gUZDPtzg== Date: Tue, 8 Jul 2025 18:14:19 +0200 From: Alejandro Colomar To: Rasmus Villemoes Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Kees Cook , Christopher Bazley , shadow <~hallyn/shadow@lists.sr.ht>, linux-kernel@vger.kernel.org, Andrew Morton , kasan-dev@googlegroups.com, Dmitry Vyukov , Alexander Potapenko , Marco Elver , Christoph Lameter , David Rientjes , Vlastimil Babka , Roman Gushchin , Harry Yoo Subject: Re: [RFC v1 0/3] Add and use seprintf() instead of less ergonomic APIs Message-ID: References: <87a55fw5aq.fsf@prevas.dk> <871pqqx035.fsf@prevas.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uc53hol6uccylkwy" Content-Disposition: inline In-Reply-To: <871pqqx035.fsf@prevas.dk> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 50EDDC0006 X-Stat-Signature: az7n5sjksyz8s7smekotkzsgpqrsymir X-HE-Tag: 1751991267-187722 X-HE-Meta: U2FsdGVkX1/vArxPYC356xMysK4/obiejeRXkpObh01erM9gQv2y7eQ1Iz4pTGOcdRB/LoGAh5RJrwdMgSalcyLOOAy1IK6pUqnHiDUFlgG1xQBnjS6AhxD+QDxiGz7AKs7KKfSl1iAS4I5Esh+6KNiQMHVUuiGKQwmuWG7KVZ3CVJD4UUW73+Cf7x23WBZIo6jUosDon1jX1bq9s54Ms1uqxT+Cg370xXA86toV778ocK665tGD/L5cFPARaXCwM3hLo1nslTiHfT+HrkkLXtLsJMz9/uu01oTKblZO0Mmuhz6MWIG5IKWrFLDoivTSukv6K7+MIrwzMUD24DritAtjspeGs44eC6l16uxgfVWC4sdcYnEPQS7gYyGJEvE9FAl2byb2hwAgVeHSkh1mm1TZ+TKYaUE84On5CIISLc0fPgC4w1yd+0Kkf6lh1IpOba+KbqaKl4Wcn0VXEBZxDdzivUNYkJvUuDC8W4+dsHrkf5i+hzQoWSLChRUrXUr8b8wHppnu+jUyKmitZcTucOfQJDdrCZyd2pBcI90z+zRqoXWEMYZXdzYklsor/tRKbUK7sFDatZqy/K9ZKi7/WqXp8eJs+ne7khOlBVqzqFTRNWcws5Ahe6Hsk61Oy40iNg9cwHg5Sob+gtZhcMCrHOhNk1Zd8s6HbPJQTmm4m3QJhuCYdZ5Ilu9MxyOd3R0MGx+QmCXHpWNnjn6DI77/MfYFfyyu49gKJZOZUY23y9WXXBVB8Cm6PIMm9a1e1L6wlZuLG0OyQeTcXBNtiy3Qyi00UDRGp7GdeZgKQLnEP2FBAXt2zsxGRwsxq2mpE5LsH2G8+/YL4gWXGa8UF9khsmBaj2lG9Kb+4CnHwOr0x37XAZv0NqFCCPr1K+ac7zwtM1tzJoKhwCmpvUjrUkIMNT6cIJk8m1xFKwVXRd1RXL3g51c1kEFXMqlcijUkPrZLvop2EPXMFGmH13U2kS9 A59Rd6al 6rHgBbVlGK+qr8uFJYI6EQD+EL1Rz93GZcOpIWqzASytJ1S6F0aGj1KXd9JKp1BfDjSy0MVmz7wI7e7h+iDo648vkqgAJQzj4qLKMR90l6uAUHtpjaDaujnJS3ZxVxzHtnjNuQZVSEAurE8wOshfRN+BB5GqxUYdACqeT19rWmQfI1geT9GWFgn6XeJnRG5hWHC5drb004nF368cFzaoa3zmzZRvVKEUIj6kEoAcLFakNZ89IS3W8Xds7z1i7+f4HXO5xaExowze2H6xEVlQI4DcOtJrk5+dNXOey4c2uPG2P7l4KVrfRe28+1kDMcYsKKDy0U9YaAWxZxjY1MXuVqMOAFafkoaPwMoZI3AZ4QXU1zT9uyFPhdB/VO7VDqBcpBhkjy/N0GGV+n6G2OiVwlhIch/lnji6Y9gOPx2kaqcaIPJJv6M7XmpPoeYjjZ1YIWwgg2U6YSd9qqggZVE8cmiCyaKCtBKSNfYwcSAWYaLw9gpY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --uc53hol6uccylkwy Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Rasmus Villemoes Cc: linux-mm@kvack.org, linux-hardening@vger.kernel.org, Kees Cook , Christopher Bazley , shadow <~hallyn/shadow@lists.sr.ht>, linux-kernel@vger.kernel.org, Andrew Morton , kasan-dev@googlegroups.com, Dmitry Vyukov , Alexander Potapenko , Marco Elver , Christoph Lameter , David Rientjes , Vlastimil Babka , Roman Gushchin , Harry Yoo Subject: Re: [RFC v1 0/3] Add and use seprintf() instead of less ergonomic APIs References: <87a55fw5aq.fsf@prevas.dk> <871pqqx035.fsf@prevas.dk> MIME-Version: 1.0 In-Reply-To: <871pqqx035.fsf@prevas.dk> Hi Rasmus, On Tue, Jul 08, 2025 at 03:51:10PM +0200, Rasmus Villemoes wrote: > > However, there's the early return due to size>INT_MAX || size=3D=3D0, > > which >=20 > First of all, there's no early return for size=3D=3D0, that's absolutely > supported and the standard way for the caller to figure out how much to > allocate before redoing the formatting - as userspace asprintf() and > kernel kasprintf() does. And one of the primary reasons for me to write > the kernel's printf test suite in the first place, as a number of the %p > extensions weren't conforming to that requirement. Yup, sorry, I was talking from memory, and forgot about the size=3D=3D0. I've introduced the check of size=3D=3D0 for seprintf(), but snprintf(3) is okay with it. My bad. The issue with INT_MAX holds. > > results in no string at all, and there's not an error code for this. > > A user might think that the string is reliable after a vsprintf(3) call, > > as it returned 0 --as if it had written ""--, but it didn't write > > anything. >=20 > No, because when passed invalid/bogus input we cannot trust that we can > write anything at all to the buffer. We don't return a negative value, > true, but it's not exactly silent - there's a WARN_ON to help find such > bogus callers. Yup, I know. It's silent to the caller, I meant. > So no, there's "no string at all", but nothing vsnprint() could do in > that situation could help - there's a bug in the caller, we point it out > loudly. Returning -Ewhatever would not remove that bug and would only > make a difference if the caller checked for that. >=20 > We don't want to force everybody to check the return value of snprintf() > for errors, and having an interface that says "you have to check for > errors if your code might be buggy", well... >=20 > In fact, returning -Ewhatever is more likely to make the problem worse; > the caller mismanages buffer/size computations, so probably he's likely > to just be adding the return value to some size_t or char* variable, > making a subsequent use of that variable point to some completely > out-of-bounds memory. That's why seprintf() controls that addition, and gives a pointer directly to the user, which doesn't need to add anything. I think this is easier to handle. There, I can report NULL for bad input, instead of adding 0. Have a lovely day! Alex >=20 > Rasmus --=20 --uc53hol6uccylkwy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmhtQ9UACgkQ64mZXMKQ wqmXexAAoMKhj1wyGjvhsWQvcONm/dFCQQmigbvdvZel7D+KJfQQSiN8AHuDL0WI +NP0JRsmbOqvnvrc8RW6w4rtmWyoRpsyJjCOCneNiw35EWmUcBbJTCXfD/A8TF9B Idf453FE2u5B4QWJ+7X2s9ee4rxKiL3MzF4iEpZ/afDa7DA4FSYBuK7bv16YfTn5 KssCG9JEH91cMLqjOuv7YgnVrHfYburjuKt9GzK5QyLinlzNvBDYl+OHRPG4OOWb 1arsLTPccpfnM0CCu2iLaCWfTDEz5W8n4ml2kwmctACzzEFUOXVm8CjC4CiRLzBu STVoHGKKn8S5KdjUxx7VdkgJmO+2a3L+J4Yq6/xP3ywlMEfXeZi3iEP/7AcBaqSo 5PR/LMx113ftA9M4/KMesyL4aB7U0EME2a0lLspvtSU64puOLa9eAcq71FcuxdQH DWRLjkLrck7s39Kwrzk/JsQO0OuAmwTqs0zV2M6aBRUCBnjfyRDrqY+PDQ1C+47z F+g8xt57alY6tN/tJFWAymozBl+6UMmI+4O8z4gL0Urso2juh1YWuH4XD5sN69iT V5ft+sw2G9VPd5T1OZYIrB8ySSgZLl3mKs0AfZr99XJsU/onPVL27ZLDfSTkEFKm NEDOPx1Ojv8NIDyKXUYid1NaofXjKbWfKF7lKsGtLanOdGYLJbU= =sxYf -----END PGP SIGNATURE----- --uc53hol6uccylkwy--