From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9138 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Non-stub setvbuf Date: Sat, 16 Jan 2016 20:43:50 -0500 Message-ID: <20160117014350.GA31121@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452995054 12307 80.91.229.3 (17 Jan 2016 01:44:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Jan 2016 01:44:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9151-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 17 02:44:13 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aKcO4-0001wb-Pu for gllmg-musl@m.gmane.org; Sun, 17 Jan 2016 02:44:12 +0100 Original-Received: (qmail 11306 invoked by uid 550); 17 Jan 2016 01:44:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 10220 invoked from network); 17 Jan 2016 01:44:03 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9138 Archived-At: 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