Re: [linuxsh-dev] gUSA committed for 2.4.18

[NIIBE Y. <gn...@m1...>]

Jeremy Siegel wrote:
 > I think the gUSA idea is really clever!

Thanks a lot.

I've tested some.  With lmbench 2.0, I can't find any performance
regressions.  I mean, there's no bad effect for the changes.  I've
been afraid that it would affect context switch time and/or signal
handling time (just slightly), but nothing.  I've tested performance
of mutual exclusion with gUSA.  The program I've used is:
	ftp://ftp.m17n.org:/pub/super-h/eaa.c
Clearly, it's efficent.

Actually, I've tested gUSA on MIPS 5900 (with PlayStation 2).  It works
well on that architecture too.

 > One suggestion though: would it be possible to put in a few more
 > checks (like limit the offset in the SP to a relatively small
 > number, and check that the current PC is within the bounds
 > specified by the implied arguments in r1 etc)?

Well, it would be.  Yes, we need to think about security issues, so
that gUSA introduces no security concerns.  For SuperH (and MIPS
R5900) implementation, gUSA mark is: SP > 0xc0000000.  I think that
it's unlikely that SP becomes such state in normal program.  Malicious
user could do that on purpose (or with buffer overflow), but it
doesn't affect system security, just the process matters.

 > BTW, when you first proposed this you said you had some pushback
 > from the general kernel community; has there been any change in
 > that?

Not so much so far.  I'll do that again, as I'm confident gUSA is
general (it's general mutual exclusion construction), generic (it
could be used on many architectures) , and gentle (no bad effect on
system) scheme.

I've written a paper for gUSA (in Japanese) for forthcoming Linux
Conference 2002.
	http://www.m17n.org/gniibe/lc02/gusa.pdf
	http://www.m17n.org/gniibe/lc02/gusa.ps
I think it's worth to translate this into English, but I have no time
for a while.

I have Sharp Zaurus (Linux based PDA), it uses SA-1100 (StrongARM).
I'll play gUSA with that.

 > Second: Even with the fix, there are still a couple __clear_user problems;
 > if there's no objection, I'd like to include the attached patch.  (First
 > hunk addresses the issue of r2 being uninitialized when you get to .Larea2
 > for a small clear; second hunk addresses a false termination of area 2.)

Oh well.  Thanks.  Please go ahead.
--