From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6E3E13856DE5 for ; Wed, 13 Jul 2022 13:33:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6E3E13856DE5 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-444-D5Z1ge7_P0iUa-PbOxdLjA-1; Wed, 13 Jul 2022 09:33:31 -0400 X-MC-Unique: D5Z1ge7_P0iUa-PbOxdLjA-1 Received: by mail-qk1-f200.google.com with SMTP id t203-20020a3746d4000000b006af1d3e8068so9899735qka.0 for ; Wed, 13 Jul 2022 06:33:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=unOm7ieSu0S2+yTFfVe5wmB2X85S17+JvjAzcRW9LS0=; b=UA3ZO2ugBJyV/QQrIMR3vNmyHmxSl4LzhCjrbpIXT+fNr/Ma8EDDV1WuaPMtH84LGc 1AgDcyNx4VNj3uJEa496ASLbgvDhMm0gc9kAPTVBFGCPmrwt4dZTLUFUOPFv61BFQUOq eopuaH9jdyLdrGUeUCRU1Ha66TakMnhRtlwiowiFcZ5S0iJOckepzOq+OUVtkhHV4o4A v6EQMJGaQDaUrhFD+nShe/Qg7oLOAUYh1P76hUw78WQs+tvY3CETtph0eeTcqTk2G8Sr XFlSMEMIvyPmPBzFU6ElAO6vUqGniBSDmj6UieqIKlpUYrtlfJ0JsuBxpXKSlqoItt83 O6TA== X-Gm-Message-State: AJIora8vDGvpyskqaFVl8yQo53/uKPNtnFYOH5a3lmRB4HCol0f7YBca ILO2KOXVraJB1VC9rFl6wMrgANDh/gnIIKl3trBkPlMFrXqKXk09vSPFq90o80N8Zi0aIqbTfwr JNtd3Ud4= X-Received: by 2002:a05:622a:152:b0:31b:bf62:9e78 with SMTP id v18-20020a05622a015200b0031bbf629e78mr2829935qtw.363.1657719210339; Wed, 13 Jul 2022 06:33:30 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tnrjfn/avWgC9SelrHFW9flmEM3R4NPsmuXDtVMJR1oGIIVhXdKFWlhSmPTJ5xH8wBdpnZrA== X-Received: by 2002:a05:622a:152:b0:31b:bf62:9e78 with SMTP id v18-20020a05622a015200b0031bbf629e78mr2829906qtw.363.1657719209983; Wed, 13 Jul 2022 06:33:29 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id e62-20020a376941000000b006a716fed4d6sm11028466qkc.50.2022.07.13.06.33.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 06:33:29 -0700 (PDT) Message-ID: <6460438cc9e634d0b5e40a1438038c9adce151bb.camel@redhat.com> Subject: Re: Adding file descriptor attribute(s) to gcc and glibc From: David Malcolm To: Florian Weimer , Szabolcs Nagy via Gcc Cc: Szabolcs Nagy , libc-alpha@sourceware.org, Mir Immad Date: Wed, 13 Jul 2022 09:33:28 -0400 In-Reply-To: <877d4h1alh.fsf@oldenburg.str.redhat.com> References: <260f0b41c663133cea96eb64bd85e8ba16d8a936.camel@redhat.com> <5769682d0d17579cbd72f72a4001bfa8444b80a8.camel@redhat.com> <877d4h1alh.fsf@oldenburg.str.redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, 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 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 13:33:35 -0000 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). Presumably if someone attempts close (AT_FDCWD); they'll get -1 and errno set to EBADFD, right? I don't think GCC's - fanalyzer needs to check for that. -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); Dave > > Thanks, > Florian >