Re: CP0 count register

On the 15th of May 2007 we exchanged emails.

> I'd never have thought to allow CP0 access to user
programs.  Certainly
> from a general standpoint you couldn't do this, since
then any user
> process can completely corrupt the machine state and
security would be
> pretty much non-existant.  That said, it seems like
what you suggest
> might work.  Just be _really_ careful which registers
you touch 

For the list archives, it turned out that the magic place to
do the 
modification to the status register is

sys/arch/mips/mips/mips_machdep.c:setregs()

  f->f_regs[_R_SR] = PSL_USERSET | MIPS_SR_COP_0_BIT;

the changes i tried in

sys/arch/mips/mips/vm_machdep.c:cpu_lwp_fork(),
cpu_setfunc()

  pcb->pcb_context[11] |= (PSL_LOWIPL|MIPS_SR_COP_0_BIT);
/* SR */

had no effect.

> I'm guessing the overhead of a gettimeofday(2) system
call is either
> too high, or not granular enough?  The way I'd probably
go about this
> if I really needed access to CP0 Count would be to add
some sort of
> fast path handling.  Perhaps add a new system call
number and check for
> it explicitly in MIPSX(SystemCall) before you set up
the kernel stack
> frame.  You could do that in a handful of instructions,
and the impact
> on normal system calls should be quite minimal.

I wasn't sure what you meant by this when you wrote it, but
now it is 
fairly clear.  I would be happy to put some effort into
modifying that 
routine and submitting code back to NetBSD if someone else
thought this 
might be a useful thing, though I guess modifying such a
critical 
function (speed-wise) is not likely to be feasible.

But, at this time I've got what I've wanted and I'm happy

On Fri, Jun 22, 2007 at 08:41:27PM +1200, Matthew Luckie
wrote:

> On the 15th of May 2007 we exchanged emails.
> 
> >I'd never have thought to allow CP0 access to user
programs.  Certainly
> >from a general standpoint you couldn't do this,
since then any user
> >process can completely corrupt the machine state
and security would be
> >pretty much non-existant.  That said, it seems like
what you suggest
> >might work.  Just be _really_ careful which
registers you touch 
> 
> For the list archives, it turned out that the magic
place to do the 
> modification to the status register is
> 
> sys/arch/mips/mips/mips_machdep.c:setregs()
> 
>  f->f_regs[_R_SR] = PSL_USERSET |
MIPS_SR_COP_0_BIT;
> 
> the changes i tried in
> 
> sys/arch/mips/mips/vm_machdep.c:cpu_lwp_fork(),
cpu_setfunc()
> 
>  pcb->pcb_context[11] |=
(PSL_LOWIPL|MIPS_SR_COP_0_BIT); /* SR */
> 
> had no effect.

I'm both happy and sorta scared that that works for you 

> >I'm guessing the overhead of a gettimeofday(2)
system call is either
> >too high, or not granular enough?  The way I'd
probably go about this
> >if I really needed access to CP0 Count would be to
add some sort of
> >fast path handling.  Perhaps add a new system call
number and check for
> >it explicitly in MIPSX(SystemCall) before you set
up the kernel stack
> >frame.  You could do that in a handful of
instructions, and the impact
> >on normal system calls should be quite minimal.
> 
> I wasn't sure what you meant by this when you wrote it,
but now it is 
> fairly clear.  I would be happy to put some effort into
modifying that 
> routine and submitting code back to NetBSD if someone
else thought this 
> might be a useful thing, though I guess modifying such
a critical 
> function (speed-wise) is not likely to be feasible.

I think in general we don't want to slow down the syscall
patch for such
a special case.  Now that I'm thinking about it again, a
perhaps better
option would be do a fast path in the illegal instruction
handler to
emulate a "mfc0 <reg>, MIPS_COP_0_COUNT"
instruction.  But I'm still not
sure that it'd be worth the effort, and it'd still be slower
than your
current (albeit I still think dangerous!) solution.

> But, at this time I've got what I've wanted and I'm
happy 

Cool!

Cheers,
Simon.