[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141027020646.GX15532@madcap2.tricolour.ca>
Date: Sun, 26 Oct 2014 22:06:46 -0400
From: Richard Guy Briggs <rgb@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: "H. Peter Anvin" <hpa@...or.com>, Eric Paris <eparis@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-audit@...hat.com
Subject: Re: [PATCH] i386/audit: stop scribbling on the stack frame
On 14/10/24, Andy Lutomirski wrote:
> On Fri, Oct 24, 2014 at 1:19 PM, H. Peter Anvin <hpa@...or.com> wrote:
> > On 10/23/2014 12:38 PM, Eric Paris wrote:
> >>> After the call __audit_syscall_entry aren't they already polluted?
> >>> Isn't that the reason we need to reload EAX?
> >>
> >> Well, I guess EAX is special...
> >
> > Because system calls are "asmlinkage", all the parameters are on the
> > stack, but %eax is used as the index into the system call table. This
> > should thus be fine until we get rid of regparm(0) entirely, if that
> > ever happens.
>
> ...and because __audit_syscall_entry *isn't* asmlinkage, it uses the
> other convention, which is where the confusion comes from. And, by
> the time you get to sysenter_do_call, nothing cares about ecx, so you
> can freely clobber it while popping from the stack. I get it now.
So you could just as easily clobber %eax since that'll be restored from
PT_EAX(%esp) anyways in the following step...
Or instead of popping these two values, could ajust the stack with
addl $8,%esp
CFI_ADJUST_CFA_OFFSET -8
since we don't need either value popped off the stack?
> --Andy
>
> > -hpa
- 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