[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1414418157.24347.1.camel@redhat.com>
Date: Mon, 27 Oct 2014 09:55:57 -0400
From: Eric Paris <eparis@...hat.com>
To: Richard Guy Briggs <rgb@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
przanoni@...il.com, mingo@...nel.org, hpa@...ux.intel.com,
hpa@...or.com, linux-tip-commits@...r.kernel.org,
linux-audit@...hat.com
Subject: Re: [PATCH] i386/audit: stop scribbling on the stack frame
My patch was already committed to the -tip urgent branch. I believe any
optimization should be based on that branch, Richard. If you are trying
to wrangle every bit of speed out of this, should you
push %esi;
push %edi;
CFI_ADJUST_CFA_OFFSET 8
call __audit_syscall_entry
pop;
pop;
CFI_ADJUST_CFA_OFFSET -8
Instead of using the pushl_cfi and popl_cfi macros?
I wrote my patch to be obviously correct, but agree there are certainly
some speedups possible.
-Eric
On Sun, 2014-10-26 at 22:34 -0400, Richard Guy Briggs wrote:
> git commit b4f0d3755c5e9cc86292d5fd78261903b4f23d4a was very very dumb.
> It was writing over %esp/pt_regs semi-randomly on i686 with the expected
> "system can't boot" results. As noted in:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=85277
>
> This patch stops fscking with pt_regs. Instead it sets up the registers
> for the call to __audit_syscall_entry in the most obvious conceivable
> way. It then does just a tiny tiny touch of magic. We need to get what
> started in PT_EDX into 0(%esp) and PT_ESI into 4(%esp). This is as easy
> as a pair of pushes using the values still in those registers.
>
> After the call to __audit_syscall_entry all we need to do is get that
> now useless junk off the stack (pair of pops) and reload %eax with the
> original syscall so other stuff can keep going about it's business.
>
> Reported-by: Paulo Zanoni <przanoni@...il.com>
> Signed-off-by: Eric Paris <eparis@...hat.com>
> Signed-off-by: Richard Guy Briggs <rgb@...hat.com>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: x86@...nel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-audit@...hat.com
>
> ---
> On 14/10/25, Thomas Gleixner wrote:
> > Why are we grabbing that from the stack? AFAICT all arguments are in
> > the registers still.
>
> Right, re-arranging the instructions slightly to avoid overwriting %edx
> with %ebx before needing it to push onto the stack, how does this look?
>
> arch/x86/kernel/entry_32.S | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index b553ed8..344b63f 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -447,15 +447,14 @@ sysenter_exit:
> sysenter_audit:
> testl $(_TIF_WORK_SYSCALL_ENTRY & ~_TIF_SYSCALL_AUDIT),TI_flags(%ebp)
> jnz syscall_trace_entry
> - addl $4,%esp
> - CFI_ADJUST_CFA_OFFSET -4
> - movl %esi,4(%esp) /* 5th arg: 4th syscall arg */
> - movl %edx,(%esp) /* 4th arg: 3rd syscall arg */
> - /* %ecx already in %ecx 3rd arg: 2nd syscall arg */
> - movl %ebx,%edx /* 2nd arg: 1st syscall arg */
> - /* %eax already in %eax 1st arg: syscall number */
> + /* movl PT_ECX(%esp), %ecx already set, a1: 3nd arg to audit */
> + /* movl PT_EAX(%esp), %eax already set, syscall number: 1st arg to audit */
> + pushl_cfi %esi /* a3: 5th arg */
> + pushl_cfi %edx /* a2: 4th arg */
> + movl %ebx, %edx /* ebx/a0: 2nd arg to audit */
> call __audit_syscall_entry
> - pushl_cfi %ebx
> + popl_cfi %ecx /* get that remapped edx off the stack */
> + popl_cfi %ecx /* get that remapped esi off the stack */
> movl PT_EAX(%esp),%eax /* reload syscall number */
> jmp sysenter_do_call
>
>
> - RGB
>
> --
> Richard Guy Briggs <rbriggs@...hat.com>
> Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
> Remote, Ottawa, Canada
> Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists