From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F53B23D2A1 for ; Thu, 19 Mar 2026 21:18:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773955128; cv=none; b=RHJdEBn0dLG4Zxhqf5gF3F7AreRVQLeyJL7CpjGz27Zy3uN95fuXckjRZ6gm4HTYw2FROFABNWSZWHoQ0CBrBUOauFXo3m9THHkR+ceTa6mUNLjCv9Pvv6bxT31IjEhdx24Tlnc4QBLA+RvAfUcRHO/Abknm42Wc9HXzj/Xp8W8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773955128; c=relaxed/simple; bh=iyGg7B3966cWSQIyN/bVLygV9d0Fu88wOZumZJmaoFs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Enj8e6KnmFFIdwfj17o5thBAQxic2RIgXpvmUqRcit9BbPT2xtJfNoTDO+d1SCui6E6UxAbYP/5Uob6inE2vBsd3dYvKhwx6qPPo+a9UjUJvmCt3IcD0vCg0++RV9zDWey3YC3p15DN80+TVRnf8ow21lJeOAs+Vy/gS56aUobE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KJ8ZnTkX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KJ8ZnTkX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89141C19424; Thu, 19 Mar 2026 21:18:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773955127; bh=iyGg7B3966cWSQIyN/bVLygV9d0Fu88wOZumZJmaoFs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KJ8ZnTkXzOfNvyMlO9orCkiawG4WdTBiPX6O1pGIfGS5nihGO/0S+S06AO1l/1upt 7XUU/0hylinxYQ9MdWqpACBUjwV2ysAJA+mm05Kjczy44jV/MK0fg4v7Yp8mbFv9UD 0ubFGXdW4umRu8ycAJEz9tH5NVuA4iC8/h1lplWRL4yVcy39ncKhT7s0LjMC1mj34E OOIc9JVTsuyl7f/60uCtG9eHyPMVs66WnQIRvHuHvF8mmDK8nxrHN02y0KCuBk5cgj INDej6+V7FzzhVJLlBJ6jX0TnZEM5Y+M8CwGI4ZYP40galHKhnCjrduIxL95SQaTkC B0Gqc+IZgSvTQ== Date: Thu, 19 Mar 2026 22:18:44 +0100 From: Alejandro Colomar To: Kees Cook Cc: LKML , corbet@lwn.net, serge@hallyn.com, Martin Uecker , linux-mm@kvack.org Subject: Re: kalloc_objs() may not be as safe as it seems Message-ID: References: <202603171402.B2BD1B1@keescook> <202603191308.ED08BC65B2@keescook> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vxxczh6pcbvzosks" Content-Disposition: inline In-Reply-To: <202603191308.ED08BC65B2@keescook> --vxxczh6pcbvzosks Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Kees Cook Cc: LKML , corbet@lwn.net, serge@hallyn.com, Martin Uecker , linux-mm@kvack.org Subject: Re: kalloc_objs() may not be as safe as it seems Message-ID: References: <202603171402.B2BD1B1@keescook> <202603191308.ED08BC65B2@keescook> MIME-Version: 1.0 In-Reply-To: <202603191308.ED08BC65B2@keescook> Hi Kees, On 2026-03-19T13:12:41-0700, Kees Cook wrote: > On Wed, Mar 18, 2026 at 05:33:35PM +0100, Alejandro Colomar wrote: > > [...] > > After sleeping, I had some idea. > >=20 > > We could have coccinelle add typeof() around the first parameter when > > it's an expression (not a type). Then, we could enforce that the first > > parameter is a type name. > >=20 > > That is: > >=20 > > p =3D kmalloc_objs(int, 42); // ok > > -q =3D kmalloc_objs(*p, 7); > > +q =3D kmalloc_objs(typeof(*p), 7); > >=20 > > I expect this would be doable with coccinelle. > >=20 > > Then, new code would be required to pass a type name. And people could > > slowly replace the existing typeof() calls at their own pace. > >=20 > > What do you think? >=20 > Well, it'd serve as a visual indicator, but it's redundant (typeof() is > already used internally). It is redundant now. But my idea would be two steps: 1) Add the redundant typeof() in the first parameter, when it's not a type already. 2) Change the kmalloc_objs() implementation so that it doesn't do typeof() internally. This would make step 1 non-redundant. > Given it would only be a potential for > confusion on integral types, I'm less convinced this needs solving. It's directly adding safety for integral types only, yes. But it's also improving readability. There's no precedent of macros that take a variable just for its type, and it feels a bit awkward to read the current one. By doing typeof(), people can relate better why it takes that parameter. If I read "q =3D kmalloc_objs(*q, 7)", the first thing I wonder is: why is this macro reading *q?? If I read "q =3D kmalloc_objs(typeof(*p), 7)", then all's fine in my brain. > For completeness, though, this Coccinelle script: >=20 > // Options: --include-headers-for-types --all-includes --include-headers = --keep-comments > virtual patch >=20 > @type_not_var depends on patch@ > type TYPE; > TYPE *VAR; > identifier ALLOC =3D > {kmalloc_obj,kzalloc_obj,kmalloc_objs,kzalloc_objs,kmalloc_flex,kzalloc_f= lex}; > @@ >=20 > VAR =3D ALLOC( > - *VAR > + TYPE > , ...) >=20 > Produces: >=20 > 6007 files changed, 12430 insertions(+), 11767 deletions(-) >=20 > Which is a lot of churn... Yeah, it would be a lot of churn if we were at rest. But since the dust has not yet settled, it might be doable. Have a lovely night! Alex --=20 --vxxczh6pcbvzosks Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmm8aC0ACgkQ64mZXMKQ wqkKsxAAvm3vo9ihoFfURqGmOQo97zkx+trQcB2AZggsZ1YnQd0+ZM8fQUXxBIwo g53D/k9qfEGqdcaf/h/rdeJ1bjFvmDbw2SK5mNzTVb/4tB0g3bAVUJW0XTAG+Bu6 iWKtC1hHLoXUbt+oU8hrEUcpLjenFc+dtw8IoeyYZvNruCCuOsyzm/mx3PwsWhve Y25DDt+Rb6bSTi5i76O+sUc12/sFUA8D8+iAudZfjbLzieE7VY2igAeZwzOfbD/6 3DF0rZInmQEGEiKiKKkkaNfiYxMm4ZzYubuFMrg498YSTWjR7WD5FgBSD+L1H6vg CqWgK8eOiA99scpHM95XzZmVVApW2h/uqtVPG9PumvQCalUlJ13OvuY3KwCktO2o 6yF3pG8kGbMqhQehJDY6hjjvwYtK5P6vUi4GlrS72GEJmCeDzZOiKuG8KclcuVFh b0WSNE8uOSo0m7wP412eSTAemc8bd7SY7fOJkG5kqwhJnfqLdwItu2n2qhEAf6R3 wj8psmq6ywPTOJWD/itgzo9oRgBjAW1gJEbx220Wj6IeTdlUMvbYquLfoRdMxaGk W4vuzWG1fOzUdvX0+kgcIQS8CjIF/yZZuF7cahPFHcMgdsgt2TC4Lx945gpzucot ikJ7Radjd3chbAPWP/kSGNoAUPfVIvIRFxH1dkSdUABd9g005cg= =fEio -----END PGP SIGNATURE----- --vxxczh6pcbvzosks--