CONFIG_FRAME_POINTER and module vermagic

CONFIG_FRAME_POINTER and module vermagic

[Christopher Friesen]

I've had a case reported to me of someone loading a module without frame 
pointers into kernel compiled with frame pointers enabled.

1) Is this allowed?  I didn't think so, but I wanted to double check.
2) If not, would it make sense to include this in the module vermagic?

Thanks,

Chris

Re: CONFIG_FRAME_POINTER and module vermagic

[linux-os (Dick Johnson)]

On Wed, 29 Mar 2006, Christopher Friesen wrote:

>
> I've had a case reported to me of someone loading a module without frame
> pointers into kernel compiled with frame pointers enabled.
>
> 1) Is this allowed?  I didn't think so, but I wanted to double check.
> 2) If not, would it make sense to include this in the module vermagic?
>
> Thanks,
>
> Chris

Frame-pointers don't affect calling conventions, only the manner
at which passed parameters are retrieved from the stack by the
called procedures. Plus, the register ebp (BP), the frame-pointer
register, is "precious" and is preserved across calls in GCC 'C'.
So, you can intermix -fno-frame-pointer code at will. It is possible
that a kernel-mode debugger may improperly display local variables,
but normally these things are not used in kernel development anyway.

So yes you can intermix such code. There is no need to flag it
in vermagic.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: CONFIG_FRAME_POINTER and module vermagic

[Christopher Friesen]

linux-os (Dick Johnson) wrote:

> Frame-pointers don't affect calling conventions, only the manner
> at which passed parameters are retrieved from the stack by the
> called procedures.

Excellent.  Thanks for the information.

Chris

Re: CONFIG_FRAME_POINTER and module vermagic

[Christopher Friesen]

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

Re: CONFIG_FRAME_POINTER and module vermagic

[Joshua Hudson]

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).

Re: CONFIG_FRAME_POINTER and module vermagic

[linux-os (Dick Johnson)]

On Tue, 4 Apr 2006, Christopher Friesen 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
>

Register EBP is used to set up a stack frame. The CPU has internal
macros that do this for you with 'enter nn' and 'leave'. Properly
used, these will also collapse the stack to its entry value,
discarding local variables when leaving the procedure.

Register EBP is an index register, considered precious by the 'C'
compiler. Such other registers are EBX, ESI, and EDI. These are
never to be destroyed by a called function.

When EBP is used for a frame pointer, it must always be
saved prior to use and restored after...

PAR1 = 0x08
PAR2 = 0x0c
PAR3 = 0x10
 		push	%ebp
 		movl	%esp, %ebp		# Enter
 		movl	PAR1(%ebp), %eax	# Get first parameter
 		movl	PAR2(%ebp), %ecx	# Get second parameter
 		movl	PAR3(%ebp), %edx	# Get third parameter
 		.........
 		.........
 		movl	%ebp, %esp		# leave
 		popl	%esp
 		ret

If a frame-pointer is not used, the code becomes.

PAR1 = 0x04
PAR2 = 0x08
PAR3 = 0x0c
 		movl	PAR1(%esp), %eax
 		movl	PAR2(%esp), %ecx
 		movl	PAR3(%esp), %edx

This saves instuctions and frees up register EBP for use as a general
purpose register, or as an index register off from the stack segment.
However, since EBP is precious, its contents must be saved before use
and restored later, as:

 		pushl	EBP
 		...........
 		...........
 		popl	EBP


Failure to do this is a BUG. If you find any code that uses either
EBP, EBX, ESI, or EDI in a called function, without first saving and
then later restoring them, it is a BUG and needs to be reported.

There is a possibility that some inline assembly was improperly
coded and ends up using some register it shouldn't, but this
would quickly lead to crash and would be descovered early in
the development phase. Note that upon entry to the kernel all
the caller's registers are saved on the intermediate kernel
stack and restored upon exit. That's what the (regs *) to which
you refer, points to. The structure member, ebp, contains the
value of the EBP register when the kernel was called. Since EBP
was the first register saved in the array, it is likely (didn't check)
that the location referenced by "regs->ebp + 4" was, in fact, the
return address. In any event, the value of regs->ebp is simply
the value in a structure member, not the value of any current
registers.

Again, you can use a stack-frame if you want, or not in your
modules. It makes no difference to the rest of the kernel.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: CONFIG_FRAME_POINTER and module vermagic

[Joshua Hudson]

> you refer, points to. The structure member, ebp, contains the
> value of the EBP register when the kernel was called. Since EBP
> was the first register saved in the array, it is likely (didn't check)
> that the location referenced by "regs->ebp + 4" was, in fact, the
> return address. In any event, the value of regs->ebp is simply
> the value in a structure member, not the value of any current
> registers.
Confirmed. This is the standard stack frame, and all debuggers assume this.