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