public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Michal Marek <mmarek@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	x86@kernel.org, live-patching@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/3] Compile-time stack frame pointer validation
Date: Mon, 11 May 2015 11:38:55 -0500	[thread overview]
Message-ID: <cover.1431362104.git.jpoimboe@redhat.com> (raw)

In discussions around the live kernel patching consistency model RFC
[1], Peter and Ingo correctly pointed out that stack traces aren't
reliable.  And as Ingo said, there's no "strong force" which ensures we
can rely on them.

So I've been thinking about how to fix that.  My goal is to eventually
make stack traces reliable.  Or at the very least, to be able to detect
at runtime when a given stack trace *might* be unreliable.  But improved
stack traces would broadly benefit the entire kernel, regardless of the
outcome of the live kernel patching consistency model discussions.

This patch set is just the first in a series of proposed stack trace
reliability improvements.  Future proposals will include runtime stack
reliability checking, as well as compile-time and runtime DWARF
validations.

As far as I can tell, there are two main obstacles which prevent frame
pointer based stack traces from being reliable:

1) Missing frame pointer logic: currently, most assembly functions don't
   set up the frame pointer.

2) Interrupts: if a function is interrupted before it can save and set
   up the frame pointer, its caller won't show up in the stack trace.

This patch set aims to remove the first obstacle by enforcing that all
asm functions honor CONFIG_FRAME_POINTER.  This is done with a new
stackvalidate host tool which is automatically run for every compiled .S
file and which validates that every asm function does the proper frame
pointer setup.

Also, to make sure somebody didn't forget to annotate their callable asm
code as a function, flag an error for any return instructions which are
hiding outside of a function.  In almost all cases, return instructions
are part of callable functions and should be annotated as such so that
we can validate their frame pointer usage.  A whitelist mechanism exists
for those few return instructions which are not actually in callable
code.

It currently only supports x86_64.  It *almost* supports x86_32, but the
stackvalidate code doesn't yet know how to deal with 32-bit REL
relocations for the return whitelists.  I tried to make the code generic
so that support for other architectures can be plugged in pretty easily.

As a first step, all reported non-compliances result in warnings.  Right
now I'm seeing 200+ warnings.  Once we get them all cleaned up, we can
change the warnings to build errors so the asm code can stay clean.

The patches are based on linux-next.  Patch 1 adds the stackvalidate
host tool.  Patch 2 is a cleanup which makes the push/pop CFI macros
arch-independent, in preparation for patch 3.  Patch 3 adds some helper
macros for asm functions so that they can comply with stackvalidate.

[1] http://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com

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 (3):
  x86, stackvalidate: Compile-time stack frame pointer validation
  x86: Make push/pop CFI macros arch-independent
  x86, stackvalidate: Add asm frame pointer setup macros

 MAINTAINERS                           |   6 +
 arch/Kconfig                          |   4 +
 arch/x86/Kconfig                      |   1 +
 arch/x86/Makefile                     |   6 +-
 arch/x86/ia32/ia32entry.S             |  60 +++---
 arch/x86/include/asm/calling.h        |  28 +--
 arch/x86/include/asm/dwarf2.h         |  92 ++++-----
 arch/x86/include/asm/frame.h          |   4 +-
 arch/x86/include/asm/func.h           |  82 ++++++++
 arch/x86/kernel/entry_32.S            | 214 ++++++++++-----------
 arch/x86/kernel/entry_64.S            |  96 +++++-----
 arch/x86/lib/atomic64_386_32.S        |   4 +-
 arch/x86/lib/atomic64_cx8_32.S        |  40 ++--
 arch/x86/lib/checksum_32.S            |  42 ++--
 arch/x86/lib/cmpxchg16b_emu.S         |   6 +-
 arch/x86/lib/cmpxchg8b_emu.S          |   6 +-
 arch/x86/lib/msr-reg.S                |  34 ++--
 arch/x86/lib/rwsem.S                  |  40 ++--
 arch/x86/lib/thunk_32.S               |  12 +-
 arch/x86/lib/thunk_64.S               |  36 ++--
 lib/Kconfig.debug                     |  11 ++
 scripts/Makefile                      |   1 +
 scripts/Makefile.build                |  22 ++-
 scripts/stackvalidate/Makefile        |  17 ++
 scripts/stackvalidate/arch-x86.c      | 134 +++++++++++++
 scripts/stackvalidate/arch.h          |  10 +
 scripts/stackvalidate/elf.c           | 352 ++++++++++++++++++++++++++++++++++
 scripts/stackvalidate/elf.h           |  56 ++++++
 scripts/stackvalidate/list.h          | 217 +++++++++++++++++++++
 scripts/stackvalidate/stackvalidate.c | 226 ++++++++++++++++++++++
 30 files changed, 1485 insertions(+), 374 deletions(-)
 create mode 100644 arch/x86/include/asm/func.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/stackvalidate.c

-- 
2.1.0


             reply	other threads:[~2015-05-11 16:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-11 16:38 Josh Poimboeuf [this message]
2015-05-11 16:38 ` [PATCH v3 1/3] x86, stackvalidate: Compile-time stack frame pointer validation Josh Poimboeuf
2015-05-13 10:39   ` Michal Marek
2015-05-13 13:51     ` Josh Poimboeuf
2015-05-11 16:38 ` [PATCH v3 2/3] x86: Make push/pop CFI macros arch-independent Josh Poimboeuf
2015-05-11 16:38 ` [PATCH v3 3/3] x86, stackvalidate: Add asm frame pointer setup macros Josh Poimboeuf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1431362104.git.jpoimboe@redhat.com \
    --to=jpoimboe@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mmarek@suse.cz \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox