[PATCH v6 0/4] Compile-time stack validation

From: Josh Poimboeuf
Date: Tue Jul 07 2015 - 10:54:57 EST


This is (another) complete rewrite of the stack validation code, based
on tip/master. The last version (v5) was named "Compile-time asm code
validation" [1]. Once again I've renamed the patch series to reflect
its changed scope. For similar reasons I've renamed the tool from
asmvalidate back to stackvalidate again.

This cover letter only describes the changes since last time. For more
information about the motivation behind this patch set, and more details
about what it does, please see the changelog in patch 2.

The biggest changes:

1. Validation of C object files

Instead of only validating hand-coded asm object code (generated from
.S files), it now also validates gcc-generated object code (from .c
files).

This change was inspired by a comment from Andy where he mentioned
some inconsistencies in how inline assembly interacts with CFI
annotations.

I did some more looking and it turns out that inline assembly doesn't
play nicely with frame pointers at all. If the inline asm is at the
beginning of the function, gcc sometimes emits the inline asm code
before setting up the frame pointer. That can break stack traces
when the inline asm has a call instruction.

That turns out to be a very common problem. Stackvalidate found 37 C
object files which break frame pointer rules, thanks to inline asm.

I don't know of a solution to this problem yet. Basically I think we
need a way to ensure that gcc emits the frame pointer setup before
inserting any inline asm (particularly when the inline asm has a call
instruction).

2. Exhaustive searching of all code paths

Several people complained that the constraints proposed in v5 were
too limiting, particularly the rule that a function can't jump
outside of its bounds. So that restriction has been removed. Now
the code is a lot smarter.

It starts at the entry to the function and recursively follows all
possible branches, tracking the frame pointer state along the way,
going outside the scope of the ELF-defined function bounds if it
needs to.

3. Support for special sections which add alternate instructions

In addition to the validation of "alternate" code in .alternative
sections, it supports fixup/exception tables, jump labels and gcc
switch statement jump tables. All of those are needed for proper
support of C object files.

4. Added documentation in Documentation/stack-validation.txt, with a
list of common warnings and what they mean.

Those are the highlights. The version log below has a more complete
list of changes.

To reduce churn, I didn't bother with fixing any of the warnings this
time around. If there's agreement on this approach, I can start
proposing fixes (but the inline asm issues still need more thinking).

Also posting a listing of the reported warnings in a reply to this
email.

[1] https://lkml.kernel.org/r/cover.1433937132.git.jpoimboe@xxxxxxxxxx

v6:
- rename asmvalidate -> stackvalidate (again)
- gcc-generated object file support
- recursive branch state analysis
- external jump support
- fixup/exception table support
- jump label support
- switch statement jump table support
- added documentation
- detection of "noreturn" dead end functions
- added a Kbuild mechanism for skipping files and dirs
- moved frame pointer macros to arch/x86/include/asm/frame.h
- moved ignore macros to include/linux/stackvalidate.h

v5:
- stackvalidate -> asmvalidate
- frame pointers only required for non-leaf functions
- check for the use of the FP_SAVE/RESTORE macros instead of manually
analyzing code to detect frame pointer usage
- additional checks to ensure each function doesn't leave its boundaries
- make the macros simpler and more flexible
- support for analyzing ALTERNATIVE macros
- simplified the arch interfaces in scripts/asmvalidate/arch.h
- fixed some asmvalidate warnings
- rebased onto latest tip asm cleanups
- many more small changes

v4:
- Changed the default to CONFIG_STACK_VALIDATION=n, until all the asm
code can get cleaned up.
- Fixed a stackvalidate error path exit code issue found by Michal
Marek.

v3:
- Added a patch to make the push/pop CFI macros arch-independent, as
suggested by H. Peter Anvin

v2:
- Fixed memory leaks reported by Petr Mladek


Josh Poimboeuf (4):
x86/asm: Frame pointer macro cleanup
x86/stackvalidate: Compile-time stack validation
x86/stackvalidate: Add file and directory ignores
stackvalidate: Add ignore macros

Documentation/stack-validation.txt | 189 ++++++++
MAINTAINERS | 8 +
arch/Kconfig | 6 +
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 6 +-
arch/x86/boot/Makefile | 3 +-
arch/x86/boot/compressed/Makefile | 3 +-
arch/x86/entry/vdso/Makefile | 5 +-
arch/x86/include/asm/frame.h | 38 +-
arch/x86/purgatory/Makefile | 2 +
arch/x86/realmode/Makefile | 4 +-
arch/x86/realmode/rm/Makefile | 3 +-
drivers/firmware/efi/libstub/Makefile | 1 +
include/linux/stackvalidate.h | 38 ++
lib/Kconfig.debug | 11 +
scripts/Makefile | 1 +
scripts/Makefile.build | 34 +-
scripts/stackvalidate/Makefile | 24 +
scripts/stackvalidate/arch-x86.c | 147 ++++++
scripts/stackvalidate/arch.h | 44 ++
scripts/stackvalidate/elf.c | 421 +++++++++++++++++
scripts/stackvalidate/elf.h | 85 ++++
scripts/stackvalidate/list.h | 217 +++++++++
scripts/stackvalidate/special.c | 176 +++++++
scripts/stackvalidate/special.h | 40 ++
scripts/stackvalidate/stackvalidate.c | 858 ++++++++++++++++++++++++++++++++++
26 files changed, 2338 insertions(+), 27 deletions(-)
create mode 100644 Documentation/stack-validation.txt
create mode 100644 include/linux/stackvalidate.h
create mode 100644 scripts/stackvalidate/Makefile
create mode 100644 scripts/stackvalidate/arch-x86.c
create mode 100644 scripts/stackvalidate/arch.h
create mode 100644 scripts/stackvalidate/elf.c
create mode 100644 scripts/stackvalidate/elf.h
create mode 100644 scripts/stackvalidate/list.h
create mode 100644 scripts/stackvalidate/special.c
create mode 100644 scripts/stackvalidate/special.h
create mode 100644 scripts/stackvalidate/stackvalidate.c

--
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/