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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <E55618B5-4535-45F7-9C61-F7DE9B98398A@zytor.com>
Date:	Thu, 23 Oct 2014 12:13:31 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>,
	Eric Paris <eparis@...hat.com>, rgb@...hat.com
CC:	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-audit@...hat.com
Subject: Re: [PATCH] i386/audit: stop scribbling on the stack frame

Well, probably not something for stable/urgent...

On October 23, 2014 11:39:48 AM PDT, Andy Lutomirski <luto@...capital.net> 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.
>
>How hard would it be to just delete it and replace it with a
>straightforward two-phase trace invocation a la x86_64?
>
>--Andy

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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/