linux-kernel - Re: [PATCH] i386/audit: stop scribbling on the stack frame

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 Oct 2014 15:15:32 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	rgb@...hat.com, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com
Subject: Re: [PATCH] i386/audit: stop scribbling on the stack frame

On Thu, 2014-10-23 at 11:39 -0700, Andy Lutomirski wrote:
> On 10/22/2014 09:04 PM, Eric Paris 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.
> > 
> > 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.
> > 
> > Signed-off-by: Eric Paris <eparis@...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
> > ---
> >  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 f9e3fab..fb01d22 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_EAX(%esp), %eax	already set, syscall number: 1st arg to audit */
> > +	movl PT_EBX(%esp), %edx		/* ebx/a0: 2nd arg to audit */
> > +	/* movl PT_ECX(%esp), %ecx	already set, a1: 3nd arg to audit */
> > +	pushl_cfi PT_ESI(%esp)		/* a3: 5th arg */
> > +	pushl_cfi PT_EDX+4(%esp)	/* a2: 4th arg */
> >  	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
> >  
> > 
> 
> This looks reasonably likely to be correct, but this code is complicated
> and now ever slower.

I guess I could just use push/pop and do the CFI_ADJUST_CFA_OFFSET by
hand.  But I figured this was reasonable enough...

> How hard would it be to just delete it and replace it with a
> straightforward two-phase trace invocation a la x86_64?

For me?  Hard.

--
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/