Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions

[Blue Swirl]

On 9/16/08, Shin-ichiro KAWASAKI <address@hidden> wrote:
> Blue Swirl wrote:
>
> >
> > >
> > > >
> > > > >  I guess the codes generated by tcg_gen_qemu_st/ld() have the same
> > > > >  restriction, because those tcg_gen functions take the argument QEMU
> > > > >
> > > >
> > > memory
> > >
> > > >
> > > > >  index flags, which is decided at translation time.  If it is true,
> the
> > > > >  restriction might be allowed for privilege check.
> > > > >
> > > > >
> > > > The loads and stores have the same problem, the generated code assumes
> > > > that the privilege mode stays the same as what it was during
> > > > translation.
> > > >
> > > >
> > >  And the other problem is that loads/stores instructions (and privilege
> > >  instructions), cannot follow some CPU status changes within one TB.
> > >  This problem will be left considering the trade off with performance.
> > >
> >
> > The loads/stores will use the ctx->memidx, but that's fine as long as
> > ctx->memidx is accurate. To ensure this, the supervisor/user bits of
> > the CPU status may not change during the TB, all instructions that
> > write to those bits must end the TB. Maybe the other instructions are
> > fine, but how about  'rte'?
> >
>
>  'rte' might cause a problem, but it will be a quite rare case, I guess.
>  Other instructions have problems too.  Those problems seems more important.
>
>  'rte' is one of the branch instructions, and it is used to return from
>  exception handling.  It has a delay slot.  So at the end of TB, delay slot
>  instruction is placed, and 'rte' is placed just in front of it.  If 'rte'
>  changes supervisor/user bits, it seems that the instruction in the delay
>  slot should follow the change.
>  But, I found that SH4 manual says that 'rte' has a restriction, that
>  no exception allowed to happen in the delay slot.  Because memory
>  load/store instructions can cause TLB exception, I guess most OSes
>  does not place memory load/store instructions in delay slot.  SH-Linux
>  places 'nop' in the delay slot.  I'm not sure about other OSes.
>  How about to check what kind of instruction is in the delay slot of 'rte'?

I guess the TB will end after the delay slot. If that is the case,
only the delay slot instruction after 'rte' will be executed with user
permissions. Is this in line with the manual?

>  By the way, special load instructions for SR ('ldc  Rm,SR' and 'ldc
> @Rm+,SR'),
>  can change supervisor/user bits.  Though I guess SH-Linux does not use it
> to
>  modify supervisor/user bits, it might be a problem for other OSes.
>
>  Similar problems happen for status of floating point unit.  The
> instructions
>  'lds Rm,FPSCR', 'lds @Rm+,FPSCR', 'frchg', and 'fschg', might change the
>  status, and confuse the translated codes.  I guess this will happen so
> often
>  on SH-Linux.
>
>  Will it be a solution to cut the TB just after these special load
> instructions?

That is the safest way, though I don't know what the bits mean. Maybe
some of the instructions can't change the interesting bits.