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 DA4F23885508 for ; Wed, 13 Jul 2022 16:55:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA4F23885508 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-376-YpNrv0iuO1yzVFdMoNj93A-1; Wed, 13 Jul 2022 12:55:53 -0400 X-MC-Unique: YpNrv0iuO1yzVFdMoNj93A-1 Received: by mail-qv1-f72.google.com with SMTP id q4-20020a0ce9c4000000b00473004919ddso4099631qvo.16 for ; Wed, 13 Jul 2022 09:55:53 -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=il8ZBXCanEDfBPvmu+GMr/kNNOb3OjEj+NVGLtJ1Gig=; b=1qIiknrHb+nTqyLkBf87Ix8YpGRxXVj4wfbDse5NUGBD3fmypsJ6OQB+FZF5PD5SXN 6Zji8Tf1DAqs6B9A2gwNB9fjz42LT/hY+4qBMKnWcJpr6CrvnmMmMe0WrLVH3a6AZtlD 3cnPH8DnQpWOb9R7vUGSrLVfXRaFHxGH7Ix7S5qL7Mp3MzJdw+oHiFl2dq1+l4Q/CWTJ /1mZqFZbcBM4HCYF33NqFRvaAW8Wol08a+KEckbPMqm4PQEJ132+jeTRatrx0Eg1FJ5S P5XOAnfsy3RFROIqolMdFbGsJMoC5avFnNqGfDk9D+KkajsjGV4nL1CXHLl3zF6gXEyk rj0g== X-Gm-Message-State: AJIora9iIb5JpWvRHTHP8sz0HOluoogkeYIQI0B2VZfTEeAqPOGqOHet PDGaTteH2/GgIGBuhf2a3wspbdn56nZa8rFT9TRBGmNkBha/lxVQd2PHdEpW5T0JMuLAT/dvDlC SalEKYCY= X-Received: by 2002:ac8:58c6:0:b0:31d:347a:ae11 with SMTP id u6-20020ac858c6000000b0031d347aae11mr3857373qta.371.1657731353059; Wed, 13 Jul 2022 09:55:53 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vCjXdqEK0rtBsXANrGJ8zZ7cbdG/MkLVHP9j3VgSCjA69ljusyrH+DWYOLs2MhJMl7Q3sBPg== X-Received: by 2002:ac8:58c6:0:b0:31d:347a:ae11 with SMTP id u6-20020ac858c6000000b0031d347aae11mr3857355qta.371.1657731352802; Wed, 13 Jul 2022 09:55:52 -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 cq12-20020a05622a424c00b0031eb5fa4b50sm6266019qtb.39.2022.07.13.09.55.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Jul 2022 09:55:52 -0700 (PDT) Message-ID: <71f2ff67c5e81ab98860d28232cba74a96c1f441.camel@redhat.com> Subject: Re: Adding file descriptor attribute(s) to gcc and glibc From: David Malcolm To: Florian Weimer Cc: Szabolcs Nagy via Gcc , Szabolcs Nagy , libc-alpha@sourceware.org, Mir Immad Date: Wed, 13 Jul 2022 12:55:50 -0400 In-Reply-To: <87tu7lyuvv.fsf@oldenburg.str.redhat.com> 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> 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=ham 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 16:55:56 -0000 On Wed, 2022-07-13 at 16:01 +0200, 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. It turns out we don't warn for that. GCC trunk's -fanalyzer implements the new warnings via a state machine for file-descriptor values; it currently has rules for handling "open", "close", "read", and "write", and these functions are currently hard- coded inside the analyzer. Here are some examples on Compiler Explorer of what it can/cannot detect: https://godbolt.org/z/nqPadvM4f Probably the most important one IMHO is the leak detection. Would it be helpful to have some kind of attribute for "returns a new open FD"? Are there other ways to close a FD other than calling "close" on it? (Would converting that to some kind of "closes" attribute be a good idea?) > > 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 … Are there any other "magic" values for file-descriptors we should be aware of? > > > -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 == "" and > AT_EMPTY_PATH.  I'm not sure if modeling all this is beneficial. Yeah, I don't think it's worth modeling things in that level of detail. In particular, I don't want to get into modeling paths in the filesystem, since that would be a huge scope-creep for the project. Thanks Dave > > Thanks, > Florian >