Date: Sat, 16 Jan 2016 20:43:50 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Non-stub setvbuf Right now, musl's stdio setvbuf function does nothing but set the buffering mode; it does not honor the buffer provided by the caller. This is perfectly conforming (whether or how the buffer is used is unspecified), but I realized from the recent thread about OpenSSH's CVE-2016-0777 on oss-security that a non-stub setvbuf admits a nice type of hardening: http://www.openwall.com/lists/oss-security/2016/01/15/15 In short, the application has no way to scrub implementation-internal stdio buffers that might contain sensitive data read from or written to files, but it can scrub buffers it provides via setvbuf. So, I'd like to start actually using the latter, so that apps that attempt this hardening measure can benefit from it on musl like they would on other implementations. The logic I have in mind is something like: - Ignore application-provided buffers smaller than UNGET (8) bytes, possibly plus some reasonable epsilon, and either turn off buffering or keep the internal buffer in this case. - If the application-provided buffer is larger than something threshold M (maybe 16k) and the file mode admits reading, only use the first M bytes of the buffer. Otherwise repeated fseek+getc is very slow (uselessly refilling a large buffer each time). Alternatively the logic to limit read buffer size could go in __stdio_read. Does this sound reasonable? I also reviewed the lack of locking in setvbuf, which looks like it risks data races accessing f->flags, but it actually seems fine since the only code that could run concurrently with it without invoking UB is __stdio_exit (or perhaps fflush(NULL)) which just checks f->rpos, f->wpos, etc. Perhaps some comments should be added to this effect, though. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.