Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
> On Fri, 2013-06-07 at 20:36 +1000, Michael Neuling wrote:
> > Currently sys_sigreturn() is TM unaware. Therefore, if we take a 32 bit
> > signal
> > without SIGINFO (non RT) inside a transaction, on signal return we don't
> > restore the signal frame correctly.
> >
> > This checks if the signal frame being restoring is an active transaction,
> > and
> > if so, it copies the additional state to ptregs so it can be restored.
> >
> > Signed-off-by: Michael Neuling <mi...@neuling.org>
> > ---
>
> .../...
>
> > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
> > + mcp = (struct mcontext __user *)&sf->mctx;
> > + tm_mcp = (struct mcontext __user *)&sf->mctx_transact;
> > + if (__get_user(msr_hi, &tm_mcp->mc_gregs[PT_MSR]))
> > goto badframe;
> > + if MSR_TM_ACTIVE(msr_hi<<32) {
>
> Mising ( and ). I'll apply that fix locally.
>
> Appart from that, I suppose it's ok. I don't see any exposure
> coming from users "cooking" the tm_frame and calling sigreturn,
> so as long as we are confident userspace generally only uses
> sigreturn with frames it got from an actual signal, and doesn't
> try to "generate" frames by hand, we should be ok.
We should add a has_cpu_feature(TM) here also in case someone cooks up
an sig frame with MSR TM active, but on a non TM CPU. This could possibly
result in a trecheckpoint on a non TM CPU hence an illegal in the
kernel.
I'll repost.
Thanks,
Mikey
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
