From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24835 invoked by alias); 16 Nov 2009 17:50:06 -0000 Received: (qmail 24823 invoked by uid 22791); 16 Nov 2009 17:50:04 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 17:48:55 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 4E3DC10D8B; Mon, 16 Nov 2009 17:48:53 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 1D4E0104AD; Mon, 16 Nov 2009 17:48:53 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1NA5h5-0006JY-R9; Mon, 16 Nov 2009 12:48:51 -0500 Date: Mon, 16 Nov 2009 17:50:00 -0000 From: Daniel Jacobowitz To: Pedro Alves Cc: Paul Pluzhnikov , gdb-patches@sourceware.org, Ulrich Weigand Subject: Re: RFC: Longjmp vs LD_POINTER_GUARD revisited Message-ID: <20091116174851.GA22887@caradoc.them.org> Mail-Followup-To: Pedro Alves , Paul Pluzhnikov , gdb-patches@sourceware.org, Ulrich Weigand References: <20091115173429.GB23483@caradoc.them.org> <8ac60eac0911151505s6834e781wf6887f0641345db@mail.gmail.com> <20091116143613.GA9703@caradoc.them.org> <200911161453.50890.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911161453.50890.pedro@codesourcery.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00368.txt.bz2 On Mon, Nov 16, 2009 at 02:53:50PM +0000, Pedro Alves wrote: > On Monday 16 November 2009 14:36:13, Daniel Jacobowitz wrote: > > On Sun, Nov 15, 2009 at 03:05:33PM -0800, Paul Pluzhnikov wrote: > > > Still it's trivial to discover the canary without disassembling > > > anything (disassembling requires symbols, which may be stripped): > > > there are only 3 different algorithms I've seen (no canary, XOR, > > > XOR+shift-by-9). Hmm, looks like x86_64 has XOR+shift-by-17 now, but > > > ia64, SPARC and PPC all have just "plain XOR". > > > > I don't know about "trivial" - could you explain how you would do this > > without disassembling? I think that at the least we'd have to call > > setjmp in the inferior, which has risks with signals / multiple > > threads / etc. I don't think we call functions in the inferior for > > discovery otherwise. > > I've had this patch below laying here for ages, that does > what Paul is suggesting, while trying to avoid infcalls. > It's quite ugly... I've been meaning to post this for ages, > but I'm a bit embarrassed by the hack :-) It doesn't work in > every possible case. So rather than disassembling setjmp to see what it is, you try various algorithms and then scan backwards looking for a call to setjmp. If you find one, you've succeeded. Sounds like it will work in an acceptable set of cases. > There are two issues that made me try this route: > > - single-stepping all the way through longjmp turned out > to be slow. Did you not perceive that too? Maybe we > could limit the amount of single-stepping by not placing > the longjmp breakpoint at 'longjmp', but at one of its callees > that's closer to the real long jump. I've only been testing on x86_64-linux native so far, where the speed is not as measurable. It didn't seem to be too many instructions. > - I've tried a similar hack as yours and found that I had > to add several more "functions still within longjmp" special > cases. I had tried it on netbsd and Windows too. NetBSD > was also bad at needing special casing. I'll post the relevant > bits of the patch in a bit, when I find it :-) I don't quite follow your patch... I'd have to sit down and stare at it for a while. So we have three strategies: * Step. Various hacks, reconcile your patch and mine (probably mostly by taking yours), test on a lot of platforms. * Infcall setjmp to examine its behavior. Risky in that infcalls are always risky. I feel like I don't have good insight into all the ways this could go wrong. * Try multiple algorithms in the target on platforms with jmp_buf encryption. You've explored these more than I have. Which one do you like best? If it's the last one, then I should pick up your attached patch... I don't think it's too awful. The only thing I don't care for is the target method for the thread area. I'd rather make the value available through the regcache. IIRC we were going to call this %fs_base at some point. -- Daniel Jacobowitz CodeSourcery