lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 06 May 2008 14:52:19 +1000 From: Greg Ungerer <gerg@...pgear.com> To: Paulo Marques <pmarques@...popie.com> CC: Sebastian Siewior <lkml@...breakpoint.cc>, torvalds@...ux-foundation.org, akpm@...ux-foundation.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] m68knommu: add pretty back strace Hi Paulo, Paulo Marques wrote: > Sebastian Siewior wrote: >> * Paulo Marques | 2008-05-02 20:27:57 [+0100]: >> >>> Greg Ungerer wrote: >>>> From: Sebastian Siewior <bigeasy@...utronix.de> >>>> With this patch and >>>> CONFIG_FRAME_POINTER=y >>>> CONFIG_KALLSYMS=y >>>> The backtrace shows resolved function names and their numeric >>>> address. >>> This is really not my area, but this patch reminds me of all the >>> dwarf2 unwinder on x86 that caused so many problems in the beginning... >>> >>>> [...] >>>> +#ifdef CONFIG_FRAME_POINTER >>>> + printk(KERN_EMERG "Call Trace:\n"); >>>> + >>>> + last_stack = stack - 1; >>>> + while (stack <= endstack && stack > last_stack) { >>>> + >>>> + addr = *(stack + 1); >>>> + printk(KERN_EMERG " [%08lx] ", addr); >>>> + print_symbol(KERN_CONT "%s\n", addr); >>>> + >>>> + last_stack = stack; >>>> + stack = (unsigned long *)*stack; >>>> } >>>> printk("\n"); >>>> +#else >>>> + printk(KERN_EMERG "CONFIG_FRAME_POINTER disabled, no symbolic >>>> call trace\n"); >>> You could probably fall back to the old method in this case, no? >> The old method printed every value from stack which was in the text >> range (you didn't get modules AFAIK). This might be the caller as well a >> function pointer as argument as well something else. I tried to find to >> find a pattern without frame pointers but I had no luck. I thing the >> caller fixed the stack frame or something. >> Greg did not complain about removing it. If you or others want the old >> method in case of no frame pointers I can send a patch. > > Having output garbled with "false positive" addresses, but that have the > "true positives" in between is better than no output at all. Yes that is a reasonable argument. But you still get the full stack hex dump, so all the raw information is there still. Just not in a decoded form. (I tended to use the raw dump more often myself anyway). >>> Also, if the stack is slightly corrupted on the top, the new method >>> might just bail out without giving any indication about the path that >>> lead there, when instead it could also fall back to the old method. >> You mean by slightly that the first caller ORed the address with >> something? > > Or more commonly, a buffer overflow... (or underflow, depending on how > the stack grows) > >> In that case we don't return safely. I don't know how I could >> find out the right time for a fallback (in case of slightly corrupted >> stack). > > I was imagining you would get a page fault where you'd show a stack > trace, but that's on a MMU processor. With no MMU I guess you don't get > a chance to do that :( > > As I said before, this is really not my area. I just remember that a > very similar change in x86 was a real pain, and wanted to make sure that > everyone here was aware of that. I would have no problem with the original full symbolic decode being in as a fall back for the non FRAME_POINTER case. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@...pgear.com Secure Computing Corporation PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists