> > I've recently implemented this for MIPS weeks ago. Running on a Indy with
> > a 180MHz R5000SC this and some other changes brought the syscall latency
> > down from somewhat more than 1.1us to 861ns. In order to implement this
> > I have to take advantage of the MIPS calling conventions which say that
> > registers $s0 - $s8 are callee saved, so they will be unchanged without
> > saving them at all. The temporary registers $at, $t0 - $t9 are not being
> > saved at all for normal subroutine calls nor do the glibc stubs expect
> > them to be. So why the heck saving them? Finally there are do_signal,
> > sys_clone() and sys_fork() which expect to find the s-registers in the
> > stackframe, we just save the s-registers into the struct pt_regs on the
> > stack in those functions because we know that gcc hasn't changed them
> > yet ...
>
> There ya go :)
>
> The one thing to remember is to zero (or otherwise trash with known to
> be zero-information data) the temp registers before returning, or
> you'll have a peephole into the kernel.
I was thinking about that and didn't consider that necessary. I don't
think we ever have the case that somebody get's an other processe's data
returned from the kernel or any other kind of sensitive data. But I
haven't really researched that.
Actually, If I remember right only systems certified to be class B are
required to burn data in registers.
Hm... garbeling all callee-saved registers is easy, one just needs to
optimize the rest of the syscall return path to waste as many registers
as possible. That's not zero, but hey, who cares if the user knows that
this syscall just called do_signal or similar?
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu