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

[Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>]

Blue Swirl wrote:
> On 9/16/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> 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?

Oh, I reviewed the manual again, and found it.

 The manual is 'SH7751 Series SH7751, SH7751R Hardware Manual'.
(It could be found with searching 'e602201_sh7751.pdf'). In section
7.1, there's a description on the status of 'rte' delay slot. 
It says,
 - instruction access is done with status before modification (supervisor mode, I guess)
 - data acess is done with status after modification (user mode)

>>  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.

Those instructions can change any bits in SR or FPSCR.
SR includes supervisor/user mode bits SR_MD, which influences ctx->memidx.
FPSCR includes the bits which decides,
 - the size of fp calculation, 32bit or 64 bit  (SZ bit and PR bit)
 - bank of register used for fp calculation (FR bit)
Current implementation in "target-sh4/translate.c" refer those
conditions at translation time, and generates the code correspond
to them.


I hope my explanation is clear enough.
Thanks for your response!

Regards,
Shin-ichiro KAWASAKI