Re: [PATCH 6/6] x86: entry_64.S: use more understandable constants
From: Andy Lutomirski
Date: Mon Feb 23 2015 - 19:37:39 EST
On Mon, Feb 23, 2015 at 4:12 PM, Denys Vlasenko <dvlasenk@xxxxxxxxxx> wrote:
> Constants such as SS+8 or SS+8-RIP are mysterious.
> In most cases, SS+8 is just meant to be SIZEOF_PTREGS,
> SS+8-RIP is RIP's offset in iret frame.
>
> This patch changes some of these constants to be less mysterious.
>
> No code changes (verified with objdump).
Applied.
>
> Signed-off-by: Denys Vlasenko <dvlasenk@xxxxxxxxxx>
> CC: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> CC: Oleg Nesterov <oleg@xxxxxxxxxx>
> CC: Borislav Petkov <bp@xxxxxxxxx>
> CC: "H. Peter Anvin" <hpa@xxxxxxxxx>
> CC: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> CC: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> CC: X86 ML <x86@xxxxxxxxxx>
> CC: Alexei Starovoitov <ast@xxxxxxxxxxxx>
> CC: Will Drewry <wad@xxxxxxxxxxxx>
> CC: Kees Cook <keescook@xxxxxxxxxxxx>
> CC: linux-kernel@xxxxxxxxxxxxxxx
> ---
> arch/x86/include/asm/calling.h | 2 ++
> arch/x86/kernel/entry_64.S | 28 ++++++++++++++++------------
> 2 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h
> index 4a7ceb9..3374235 100644
> --- a/arch/x86/include/asm/calling.h
> +++ b/arch/x86/include/asm/calling.h
> @@ -88,6 +88,8 @@ For 32-bit we have the following conventions - kernel is built with
> #define RSP 19*8
> #define SS 20*8
>
> +#define SIZEOF_PTREGS 21*8
> +
> .macro ALLOC_PT_GPREGS_ON_STACK addskip=0
> subq $15*8+\addskip, %rsp
> CFI_ADJUST_CFA_OFFSET 15*8+\addskip
> diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> index c628a1b..2fa9e59 100644
> --- a/arch/x86/kernel/entry_64.S
> +++ b/arch/x86/kernel/entry_64.S
> @@ -164,12 +164,12 @@ ENDPROC(native_usergs_sysret64)
> * initial frame state for interrupts (and exceptions without error code)
> */
> .macro INTR_FRAME start=1 offset=0
> - EMPTY_FRAME \start, SS+8+\offset-RIP
> - /*CFI_REL_OFFSET ss, SS+\offset-RIP*/
> - CFI_REL_OFFSET rsp, RSP+\offset-RIP
> - /*CFI_REL_OFFSET rflags, EFLAGS+\offset-RIP*/
> - /*CFI_REL_OFFSET cs, CS+\offset-RIP*/
> - CFI_REL_OFFSET rip, RIP+\offset-RIP
> + EMPTY_FRAME \start, 5*8+\offset
> + /*CFI_REL_OFFSET ss, 4*8+\offset*/
> + CFI_REL_OFFSET rsp, 3*8+\offset
> + /*CFI_REL_OFFSET rflags, 2*8+\offset*/
> + /*CFI_REL_OFFSET cs, 1*8+\offset*/
> + CFI_REL_OFFSET rip, 0*8+\offset
> .endm
>
> /*
> @@ -177,7 +177,7 @@ ENDPROC(native_usergs_sysret64)
> * with vector already pushed)
> */
> .macro XCPT_FRAME start=1 offset=0
> - INTR_FRAME \start, RIP+\offset-ORIG_RAX
> + INTR_FRAME \start, 1*8+\offset
> .endm
>
> /*
> @@ -644,10 +644,14 @@ END(interrupt)
> cmovzq PER_CPU_VAR(irq_stack_ptr),%rsp
> CFI_DEF_CFA_REGISTER rsi
> pushq %rsi
> + /*
> + * For debugger:
> + * "CFA (Current Frame Address) is the value on stack + offset"
> + */
> CFI_ESCAPE 0x0f /* DW_CFA_def_cfa_expression */, 6, \
> - 0x77 /* DW_OP_breg7 */, 0, \
> + 0x77 /* DW_OP_breg7 (rsp) */, 0, \
> 0x06 /* DW_OP_deref */, \
> - 0x08 /* DW_OP_const1u */, SS+8-RBP, \
> + 0x08 /* DW_OP_const1u */, SIZEOF_PTREGS-RBP, \
> 0x22 /* DW_OP_plus */
> /* We entered an interrupt context - irqs are off: */
> TRACE_IRQS_OFF
> @@ -673,7 +677,7 @@ ret_from_intr:
>
> /* Restore saved previous stack */
> popq %rsi
> - CFI_DEF_CFA rsi,SS+8-RBP /* reg/off reset after def_cfa_expr */
> + CFI_DEF_CFA rsi,SIZEOF_PTREGS-RBP /* reg/off reset after def_cfa_expr */
> /* return code expects complete pt_regs - adjust rsp accordingly: */
> leaq -RBP(%rsi),%rsp
> CFI_DEF_CFA_REGISTER rsp
> @@ -1539,7 +1543,7 @@ first_nmi:
> .rept 5
> pushq_cfi 11*8(%rsp)
> .endr
> - CFI_DEF_CFA_OFFSET SS+8-RIP
> + CFI_DEF_CFA_OFFSET 5*8
>
> /* Everything up to here is safe from nested NMIs */
>
> @@ -1567,7 +1571,7 @@ repeat_nmi:
> pushq_cfi -6*8(%rsp)
> .endr
> subq $(5*8), %rsp
> - CFI_DEF_CFA_OFFSET SS+8-RIP
> + CFI_DEF_CFA_OFFSET 5*8
> end_repeat_nmi:
>
> /*
> --
> 1.8.1.4
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
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/