[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140515223222.GA9727@pizzadoos.com>
Date: Fri, 16 May 2014 00:32:22 +0200
From: Erik Bosman <erik@...emu.org>
To: Andi Kleen <andi@...stfloor.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] x86: SROP mitigation: implement signal canaries
On Thu, May 15, 2014 at 02:31:40PM -0700, Andi Kleen wrote:
> Erik Bosman <erik@...emu.org> writes:
>
> >
> > diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> > index 2206757..1a9285a 100644
> > --- a/arch/x86/ia32/ia32_signal.c
> > +++ b/arch/x86/ia32/ia32_signal.c
> > @@ -212,9 +212,18 @@ asmlinkage long sys32_sigreturn(void)
> > struct sigframe_ia32 __user *frame = (struct sigframe_ia32 __user *)(regs->sp-8);
> > sigset_t set;
> > unsigned int ax;
> > +#ifdef CONFIG_SIGNAL_CANARY
> > + u32 canary;
> > +#endif
>
> Don't you completely break the ABI here? I'm sure there are programs out
> there who hard code the offset into the FP state.
>
> I think you either need to put it at the total end or somewhere
> currently unused
>
Hrmz.. FP state is aligned on a 64 byte boundary, the signal frame (separately)
on a 16 byte-sizeof(long) boundary. But it looks like that for 32 and 64 bit
rt_sigreturn this means no padding :-/
It looks like I'll have to put the canary beyond the fp state. :-(
I had hoped to avoid pointer arithmetic. :-/
Erik
> Besides that I would remove the CONFIG_* once it works and just do it
> unconditionally.
>
> -Andi
>
>
> --
> ak@...ux.intel.com -- Speaking for myself only
> --
> 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/
>
--
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