Re: CONFIG_FRAME_POINTER and module vermagic

["Joshua Hudson" <joshudson@gmail.com>]

On 4/4/06, Christopher Friesen <cfriesen@nortel.com> wrote:
>
> A while back there was a post that CONFIG_FRAME_POINTER doesn't affect
> calling conventions and doesn't need to be in vermagic.
>
> One of my coworkers seems to think otherwise, and I don't know enough
> about the issue to know for sure.  Could someone with i386 knowledge
> comment on his thoughts?
>
> Here's what he's currently thinking:
>
> 1) regs->ebp hold a copy of the stack frame pointer. It's value is
> conserved through any function that are compiled with FRAME_POINTER on.
>
> 2) (unsigned long *)(regs->ebp + 4) is the "pc" of the caller (like the
> link register on PPC which is relative to "fp")
>
> 3) The profile_pc function usually look directly at "pc" to do it's
> profiling magic but sometimes (when the current "pc" is inside a
> lock_function, we're SMP, and CONFIG_FRAME_POINTER is enabled) it uses
> "regs->ebp+4" to be more accurate on the profiling. In other word
> profile_pc doesn't want to create a profiling entry that would show
> redundant information about being stuck into a spin_lock...
>
> So, if the kernel was built with SMP and FRAME_POINTER, a module wasn't,
> the module used ebp as a general register, then blocked in a spinlock
> when profile_pc started...then a regs->ebp value of something
> interesting (like "0", for instance) could cause interesting behaviour.
>
> Seems reasonable to me, but like I said, I'm not an expert on i386.
>
> Chris
1. The calling convention of i386 requires that i386 function calls preserve ebp
(like esi).
2. Therefore, this will only affect code that actually looks at the
stack frame would
have to care.
3. Notice that profile_pc itself is compiled with frame pointers on in
this case and reads the PC [IP] of its own caller.
4. Therefore, the only thing that has to care is the kernel segfault handler.

The kernel segfault handler itself is not properly hardened against
this (it likes to generate recursive die() failure). I know: I've
smashed my own stack working on kernel code.

IMO, the problem here is not linking frame-pointer using code with
non-frame-pointer using code, but failing to harden the segfault
handler against a smashed stack frame
(which is exactly what using ebp as a general register looks like).