This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Omit frame pointer and fix %ebp by default on x86 (take3)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Jeffrey A Law <law at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Andrew Haley <aph at redhat dot com>, <gcc-patches at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Thu, 19 Aug 2004 09:57:11 -0600 (MDT)
- Subject: Re: [PATCH] Omit frame pointer and fix %ebp by default on x86 (take3)
On Mon, 16 Aug 2004, Jeffrey A Law wrote:
> Do the new versions of oprofile need this data? They have some
> limited capability to get backtraces when events occur and I thought
> it used the frame pointer to do that (otherwise we'd have to do
> something ugly like embed a dwarf2 frame unwinder into the kernel and
> run it when events occur -- not good).
I've checked and indeed the call-graph patch to "oprofile" requires a
frame-pointer to report the call-graph. However, as pointed out in
that patch's documentation, this requires the Linux kernel to be rebuild
with CONFIG_FRAME_POINTER to allow it to profile the kernel, as most
distributions omit the frame poiner by default.
Taking a slightly different tack, preserving the frame pointer in
executables that don't need it is a potential security vulnerability.
The ability to walk back through stack frames inspecting PCs allows
a "code insertion/buffer overflow" attack to subvert even recent
position-independent-executable (PIE) security polices. By knowing
how many frames deep an exploit is within a known executable, the
attacking code can unwind to a known reference point in both the
executable, libc and maybe even the kernel. Once the exploit has
the relocated address of __libc_start_main in libc.so, its possible
to invoke system library functions without link-time support.
Omitting frame pointers makes this process significantly harder.
This only affects x86 applications built with GCC that aren't compiled
with -fomit-frame-pointer. Software build with compilers that don't
reserve %ebp for a frame pointer, such as Microsoft's and Intel's,
should be unaffected.
Ok, its a long shot...