From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 271EA3858CDA for ; Tue, 11 Jul 2023 00:50:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 271EA3858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <20230710161300.1678172-1-xry111@xry111.site> <60947356-1710-4658-9169-9535505befd4@app.fastmail.com> <5d050e86-4c98-de22-5ef0-4cc9ead273d7@gotplt.org> <18affbe3-00c1-1cb1-6860-f7c78585f52b@gotplt.org> <25b31a74-5f06-1cce-dca5-ae84666c92b7@gmail.com> <2b0a78ff42fb00b92cf7a2d940dfeb141b0dfcfe.camel@xry111.site> <7ae4346f-f803-4d0f-8317-04a6d2ea2116@app.fastmail.com> User-agent: mu4e 1.10.4; emacs 29.0.92 From: Sam James To: Siddhesh Poyarekar Cc: Zack Weinberg , Xi Ruoyao , Jeff Law , Adhemerval Zanella , Carlos O'Donell , "'Alejandro Colomar (man-pages)'" , Andreas Schwab , David Malcolm , libc-alpha@sourceware.org Subject: Re: [PATCH v5] libio: Add nonnull attribute for most FILE * arguments in stdio.h Date: Tue, 11 Jul 2023 01:45:28 +0100 In-reply-to: Message-ID: <87ilarxodp.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Siddhesh Poyarekar writes: > On 2023-07-10 17:22, Zack Weinberg wrote: >>> Why it's not OK if no externally visible side effects is between the two >>> points? >> The short answer is that the C standard's definition of "externally >> visible side effect" is insufficient for the needs of certain >> security-critical programs. In particular, *how long it takes for >> the program to crash* may be an exploitable timing channel. (Look up >> "bomb oracle attack" in the cryptography literature if that seems >> impossible.) >>=20 > > Those kinds of security-critical applications (also the kinds that > need time-invariant copy routines) shouldn't be the main target for > the library, although it would be a good idea to have special switches > to enable code for them. > >>> So what should we do now? Remove all __nonnull from the headers? >> That would be my choice. Or, leave them in as documentation, but >> make the macro expand to nothing except with specific compilers that >> are known not to optimize unsafely (this may be an empty set at >> present) I've CC'd all the participants in this thread on the GCC bug that Xi Ruoyao filed, but some of these attributes have (IIRC) been around for decades (2004!): * https://github.com/madler/pigz/issues/107#issuecomment-1368304437 * https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3Dbe27d08c0591= 1a658949ba7b84f4321a65a2dbf4 I don't like making this argument if something is unsound (because if it's unsound, then it always has been), but this is purely about working around buggy applications anyway - and clearly nobody's been bothered by this in the last 20 years, at least enough to report a bug? >>=20 >>> Or "some __nonnull are OK but my is not"?! >> I don't like that we have __nonnull at all. But adding it to stdio.h >> functions in particular is especially dangerous because of how >> widely used they are. I would say the same thing if you were adding >> it to string.h or stdlib.h. > > It's already very widely deployed in glibc, I doubt if adding to > stdio.h would make it significantly worse. Right. And the attribute is also going to be *significantly* nerfed if we drop it globally from our headers in glibc, as nobody gets warnings for stdlib functions anymore. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZKynUl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZBNTwD/SLAjrQanN5BAt7KtV6SWPJ7EbDlhnpDb6kv9 FNrsxQ8A/A+hFBhD5/cG7HrubWfND60YxRmzgX7/g6IVmJg6SYMJ =nWE/ -----END PGP SIGNATURE----- --=-=-=--