Re: Adding file descriptor attribute(s) to gcc and glibc

[Florian Weimer <fweimer@redhat.com>]

* 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 …

> -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.

Thanks,
Florian