This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New read etc. checking macros


> Another, which has the advantage that no new @GLIBC_2.4 entrypoints are
> needed, does the checking in the caller, either at compile time if the
> compiler can optimize it at compile time, or at runtime if not.

The recent *_chk additions that Ulrich implemented have different semantics
than this.  I wonder which is really preferable.  What is in now for
e.g. {p,f,}read_chk does the most conservative checking.  That is, it does
not fail unless the buffer would actually have been overrun by the read.
This obviously avoids breaking anything that would not already have been
biting in test cases already tried.  But to me, that conservatism is more
of a detriment than an advantage.  This conservative approach also requires
more intricate implementation work than does what you've suggested, as well
as introducing many new ABI symbols.

Currently, a program can do:

	char buf[10];
	ssize_t n = read(0, buf, 20);

and get no failures as long as the input available to be read happens to be
no more than 10 bytes.  So, the program gets __chk_fail instead of
clobbering.  But there is nothing here that helps a program notice early
that it is vulnerable to that failure given some possible input.

I would like to see this do the simple check that Jakub's third example
does.  If the NBYTES argument is larger than what BUF points to, it should
fail immediately.  In fact, when the compiler can detect this statically it
might as well diagnose it directly, i.e. as if the prototype were:

ssize_t read(int fd, char buf[nbytes], size_t nbytes);


I can imagine reading POSIX to say that this is not in fact invoked
undefined behavior when there is some external guarantee such as the
program knowing that the file being read contains no more than 10 bytes.
The standard C functions' specifications talk more explicitly about an
array (for e.g. fgets and fread), so the strict reading might not be as
permissive for those as for the POSIX functions like read.  Regardless,
this is desireable checking for the way people usually write their programs.
Perhaps it should be done only at _FORTIFY_SOURCE >= 2.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]