Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1179163
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation |
| Date | 2015-07-08 01:50 +0200 |
| Message-ID | <pJKMF-3Fu-1@gated-at.bofh.it> (permalink) |
| References | <pJCvM-6Ty-11@gated-at.bofh.it> <pJCvM-6Ty-17@gated-at.bofh.it> <pJK0i-39I-17@gated-at.bofh.it> <pJKtk-3yX-11@gated-at.bofh.it> <pJKCZ-3C7-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Jul 07, 2015 at 04:35:17PM -0700, Andy Lutomirski wrote: > On Tue, Jul 7, 2015 at 4:29 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > > On Tue, Jul 07, 2015 at 03:57:14PM -0700, Andy Lutomirski wrote: > >> On Tue, Jul 7, 2015 at 7:54 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote: > >> > > >> > It currently only supports x86_64. I tried to make the code generic so > >> > that support for other architectures can hopefully be plugged in > >> > relatively easily. > >> > > >> > Currently with my Fedora config it's reporting over 1400 warnings, but > >> > most of them are duplicates. The warnings affect 37 .c files and 18 .S > >> > files. The C file warnings are generally due to inline assembly, which > >> > doesn't seem to play nice with frame pointers. > >> > >> This issue might be worth bringing up on the gcc and binutils lists. > >> If we need better toolchain support, let's ask for it. > > > > I think we found a good solution for this. See my update at: > > > > https://lkml.kernel.org/r/20150707223519.GA31294@treble.redhat.com > > Does that force frame pointer generation? If so, then once we have a > real kernel unwinder, we might want a non-frame-pointer-forcing > version for better code generation. (That can wait, of course.) I strongly doubt it would force frame pointer generation if -fomit-frame-pointer is set. But I'll verify :-) > >> > + > >> > + This is a context switch instruction like sysenter or sysret. Such > >> > + instructions aren't allowed in a callable function, and are most > >> > + likely part of kernel entry code. > >> > + > >> > + If the instruction isn't actually in a callable function, change > >> > + ENDPROC to END. > >> > + > >> > + > >> > +6. stackvalidate: asm_file.o: func()+0x26: jump to outside file from callable function > >> > + or > >> > + stackvalidate: asm_file.o: func()+0xd9: jump to dynamic address from callable function > >> > + > >> > + These are constraints imposed by stackvalidate so that it can > >> > + properly analyze all jump targets. Dynamic jump targets and jumps to > >> > + code in other object files aren't allowed. > >> > >> Does this not trigger due to optimized sibling calls to different files? > > > > This is a great point. With CONFIG_FRAME_POINTER it's not a problem, > > because it adds -fno-optimize-sibling-calls. > > > > Without it, I think stackvalidate would spit out a ton of "jump to > > outside file" warnings. > > > > I haven't yet looked at the details of how exactly sibling calls work. > > I'd assume they're disabled because they break frame pointers somehow. > > Any idea if they'd also break DWARF CFI stack traces? > > They'll certainly prevent unwinding from finding the pre-optimization > caller, but the rest of unwinding should work. I don't know why we > turn it off, though. > > You might want special-case jump-out-of-translation-unit to be okay if > the stack frame is in its initial state. That is: > > func: > jmp elsewhere > > could be considered okay, as could: > > func: > push %rax > pop %rax > jmp elsewhere > > and similar. Ah, nice idea. That might cover all the cases. I'll try it. > > > > > I probably need to do some digging there. If sibling calls don't break > > CFI stack traces and we end up needing them, stackvalidate might need to > > analyze the entire kernel image at once instead of its current per-.o > > checking. > > > > Anyway, thanks a bunch for all your insightful feedback Andy! > > > > I'm just pretending to be insightful :) Insightful or not, your comments have been very helpful! -- Josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation Andy Lutomirski <luto@amacapital.net> - 2015-07-08 01:00 +0200
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation Josh Poimboeuf <jpoimboe@redhat.com> - 2015-07-08 01:30 +0200
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation Andy Lutomirski <luto@amacapital.net> - 2015-07-08 01:40 +0200
Re: [PATCH v6 2/4] x86/stackvalidate: Compile-time stack validation Josh Poimboeuf <jpoimboe@redhat.com> - 2015-07-08 01:50 +0200
csiph-web