From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/157 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts review Date: Thu, 14 Jul 2011 01:44:59 +0400 Message-ID: <20110713214459.GA26971@openwall.com> References: <20110713110723.GA22153@openwall.com> <4E1D8964.3020502@gmail.com> <20110713160327.GA24660@openwall.com> <4E1DCDE5.1040008@gmail.com> <20110713170551.GA25095@openwall.com> <4E1DD4F3.5090206@gmail.com> <20110713175201.GA25532@openwall.com> <4E1DF202.4000106@gmail.com> <20110713203945.GA26271@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1310593511 21280 80.91.229.12 (13 Jul 2011 21:45:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 21:45:11 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-241-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 13 23:45:06 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qh7Eu-0001L5-LU for gllmg-musl@lo.gmane.org; Wed, 13 Jul 2011 23:45:04 +0200 Original-Received: (qmail 9419 invoked by uid 550); 13 Jul 2011 21:45:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9411 invoked from network); 13 Jul 2011 21:45:04 -0000 Content-Disposition: inline In-Reply-To: <20110713203945.GA26271@openwall.com> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:157 Archived-At: On Thu, Jul 14, 2011 at 12:39:45AM +0400, Solar Designer wrote: > Rich might be able to provide a better / more correct answer (I'd be > interested), but here's my understanding: > > The clobbering happens when those variables are kept in registers rather > than in memory (on stack). To prevent it from happening, you may force > the compiler not to place the variables in registers. One way to do it > is to take the variable's address: > > (void) &var; > > (I am not sure what guarantees this provides. IIRC, it was documented > to provide the needed safety under GNU C.) I can't find where I think I previously saw this documented for gcc. > Another is to declare it "volatile", but this does a bit more than is > needed (so has extra performance impact). This is documented in lots of places. For example: https://www.securecoding.cert.org/confluence/display/seccode/MSC22-C.+Use+the+setjmp(),+longjmp()+facility+securely and indeed we're taking a risk by potentially interrupting and re-entering non-async-signal safe functions: https://www.securecoding.cert.org/confluence/display/seccode/SIG32-C.+Do+not+call+longjmp%28%29+from+inside+a+signal+handler IIRC, I brought this up before, and Rich correctly pointed out that we were doing it for low-risk functions only, and this is only a test suite. > Better yet, structure your function such that there are no variables to > clobber. If you put your sigsetjmp() at the very beginning of the > function, before any local variable is assigned a value, there's nothing > to clobber yet. Here's an example: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/protocol.c?rev=HEAD int pop_handle_state(struct pop_command *commands) { char line[POP_BUFFER_SIZE]; char *params; struct pop_command *command; int response; if (sigsetjmp(pop_timed_out, 1)) return POP_CRASH_NETTIME; while (pop_get_line(line, sizeof(line))) { ... It also invokes siglongjmp() from a signal handler, but it only installs the handler for the duration of a read() syscall, which is async signal safe, so there's no risk. Alexander