iwmmxt signal frame handling

[Nicolas Pitre]

On Fri, 15 Oct 2010, Eric Miao wrote:

> On Fri, Oct 15, 2010 at 9:40 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> > On Friday 15 October 2010 15:32:04 Eric Miao wrote:
> >> > Acked-by: Eric Miao <eric.y.miao at gmail.com>
> >> >
> >>
> >> This also passes the internal iwmmxt test, Haojian please add your
> >> Tested-by please.
> >
> > Can you also confirm that the previous behaviour is broken?
> > If it is, the patch is probably a candidate for the stable trees.
> >
> 
> I don't believe the previous behavior is going to cause any serious issue. The
> magic/size are only saved/restored only for those processes with
> TIF_USING_IWMMXT
> flag set. Yet this patch does seem to improve from security perspective by
> zero-ing the buffer.
> 
> BTW: I didn't look too much into the code, but it seems to me that the aux can
> just be zero-ed in a whole?

No.  Extensions to the ucontext layout are structured into:

	- magic number to identify the data

	- size of the data

	- the data itself

and you may have multiple of those blocks together, with the last one 
having a magic number of 0 to mark the end.

What could be done instead is to avoid copying any iwmmxt context when 
that is not available (i.e. when TIF_USING_IWMMXT is not set), but that 
would make the code more complex as the ucontext structure couldn't be 
used as is and some kind of dynamic storage woule be needed.  I really 
doubt it is worth the trouble, especially since the only environment 
where that would make a difference is with those old pre-EABI binaries 
which don't care at all about those ucontext extensions anyway.


Nicolas