From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 11F13382C14C for ; Wed, 13 Jul 2022 16:56:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 11F13382C14C Received: by mail-pj1-x1032.google.com with SMTP id q5-20020a17090a304500b001efcc885cc4so4588710pjl.4 for ; Wed, 13 Jul 2022 09:56:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zh9ineak9+GZ4blbs+zIyQRxjNmgPJQTyAnqTe8S2t8=; b=M4iiFxcY8UCZVTWIdK3AqfGzCk3mJC+P3tHBGBDn/vOZ73YMIJ2g/LDb/qcD8VxT8s pRaaVw0YRPBu6TGZZFpYgL/wr32Cyqi4Pb+mKNzcnOOI2P2UDsNajhgRazq03sB5C0u2 rW809qqFVCB1UGLIaV/Nc8LQG3CKdhnYh0x9FbSEU2ZO/jBsdzux4g3W4rlR7H9yG4Gt W8dXWDrPys6rvd+IhYdjDkuN44mjcrJfGQQ+6mhJBo/8iw+CBawIELUIAgLZ4yR85q4M GqX44fjAXBhnkVVoqTPTodZYZIKPJMx7pijRiHyvKtRw+SqFwLEBiyRqEVejzHYoZBjT tOjA== X-Gm-Message-State: AJIora8v64eKEd2u6s4mD/4bJL/WEjR53JoVQoMemJcIUyPtJejprI8q wUqwPL+T39wG5P60Po6wjG0BgnOJn+ihfqREy0M= X-Google-Smtp-Source: AGRyM1tcY4Qi4PBYut+kxZqx2Bk9+3/X+WjFNQqIE4yqaDZKfqMmFXTPGdgxnWmuriMt2KINA1T1xKBQ401gYcx4Vvg= X-Received: by 2002:a17:903:28e:b0:16a:3bea:11eb with SMTP id j14-20020a170903028e00b0016a3bea11ebmr4226143plr.154.1657731414961; Wed, 13 Jul 2022 09:56:54 -0700 (PDT) MIME-Version: 1.0 References: <260f0b41c663133cea96eb64bd85e8ba16d8a936.camel@redhat.com> <5769682d0d17579cbd72f72a4001bfa8444b80a8.camel@redhat.com> <877d4h1alh.fsf@oldenburg.str.redhat.com> <6460438cc9e634d0b5e40a1438038c9adce151bb.camel@redhat.com> <87tu7lyuvv.fsf@oldenburg.str.redhat.com> In-Reply-To: <87tu7lyuvv.fsf@oldenburg.str.redhat.com> From: Mir Immad Date: Wed, 13 Jul 2022 22:26:44 +0530 Message-ID: Subject: Re: Adding file descriptor attribute(s) to gcc and glibc To: Florian Weimer Cc: David Malcolm , Szabolcs Nagy via Gcc , Szabolcs Nagy , libc-alpha@sourceware.org X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 16:56:59 -0000 Hi everyone, Reading through the thread, I feel the following attributes look good and similar to what I've done: __attribute__ ((fd_arg(N))) __attribute__ ((fd_arg_read(N))) __attribute__ ((fd_arg_write(N))) I believe how to annotate the glibc headers is a separate discussion. Dave: From the GCC side of things, these three attributes are basic functionalities that can be useful for any piece of code that passes around file descriptors. Thanks Immad On Wed, Jul 13, 2022 at 7:31 PM Florian Weimer wrote: > * David Malcolm: > > > On Wed, 2022-07-13 at 14:05 +0200, Florian Weimer wrote: > >> * Szabolcs Nagy via Gcc: > > > > [adding Immad back to the CC list] > > > >> > >> > to be honest, i'd expect interesting fd bugs to be > >> > dynamic and not easy to statically analyze. > >> > the use-after-unchecked-open maybe useful. i would > >> > not expect the access direction to catch many bugs. > >> > >> You might be right. But I think the annotations could help to catch > >> use-after-close errors. > >> > >> By the way, I think it would help us if we didn't have to special- > >> case > >> AT_FDCWD using inline wrappers. > > > > Florian: I confess I wasn't familiar with AT_FDCWD until I read your > > email and did a little reading a few minutes ago; it seems to be a > > "magic number" for an FD that has special meaning; on my system it has > > the value -100. > > > > GCC's current implementation of the various -Wanalyzer-fd-* warnings > > will track state for constant integer values as well as symbolic > > values; it doesn't have any special meanings for specific integer > > values. So e.g. it doesn't assume that 0, 1, and 2 have specific > > meaning or are opened with specific flags (the analysis doesn't > > necessarily begin its execution path at the start of "main", so there's > > no guarantee that the standard FDs have their standard meaning). > > Ahh. It might be useful to detect close (-1) etc. as a form of > double-close, and ther AT_FDCWD is exceptional. > > > Presumably if someone attempts > > close (AT_FDCWD); > > they'll get -1 and errno set to EBADFD, right? > > Correct > > > I don't think GCC's -fanalyzer needs to check for that. > > Not sure =E2=80=A6 > > > -fanalyzer's filedescriptor support doesn't yet have a concept of > > "directory filedescriptors". Should it? (similarly, it doesn't yet > > know about sockets) > > > > A possible way to annotate "openat": > > > > int openat(int dirfd, const char *pathname, int flags) > > __attr_fd_arg(1); > > openat is not the most general interface in this regard. We have other > *at functions which accept an O_PATH descriptor (or maybe even a > different kind of non-directory descriptor) with pathname =3D=3D "" and > AT_EMPTY_PATH. I'm not sure if modeling all this is beneficial. > > Thanks, > Florian > >