From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KepkO-0007SB-IP for qemu-devel@nongnu.org; Sun, 14 Sep 2008 07:26:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KepkL-0007Ps-68 for qemu-devel@nongnu.org; Sun, 14 Sep 2008 07:26:30 -0400 Received: from [199.232.76.173] (port=50822 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KepkL-0007Pp-3P for qemu-devel@nongnu.org; Sun, 14 Sep 2008 07:26:29 -0400 Received: from wf-out-1314.google.com ([209.85.200.170]:32886) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KepkK-0001tg-4S for qemu-devel@nongnu.org; Sun, 14 Sep 2008 07:26:28 -0400 Received: by wf-out-1314.google.com with SMTP id 27so1564019wfd.4 for ; Sun, 14 Sep 2008 04:26:22 -0700 (PDT) Message-ID: Date: Sun, 14 Sep 2008 14:26:22 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions In-Reply-To: <48CCE727.7000203@juno.dti.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CC8D3E.1040401@juno.dti.ne.jp> <48CCE727.7000203@juno.dti.ne.jp> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 9/14/08, Shin-ichiro KAWASAKI wrote: > Thank you for the comment! > > Blue Swirl wrote: > > > On 9/14/08, Shin-ichiro KAWASAKI wrote: > > > > > This patch adds check for all SH4 instructions which are > > > executed only in privileged mode. > > > > > > > The checks get the privileged mode status from translation context. In > > theory, the same TB code block could be used in unprivileged and > > privileged mode, so the status that was true at translation time may > > no longer be correct at execution time. Of course normally kernel code > > is not visible or executable to user processes. > > > > As you say, this patch has the restriction that you pointed out : the > generated TB cannot used for both unprivileged and privileged. Qemu will happily use the same TB for both modes, if the TB flags match (cpu-exec.c): if (unlikely(!tb || tb->pc != pc || tb->cs_base != cs_base || tb->flags != flags)) { tb = tb_find_slow(pc, cs_base, flags); } > 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. > > The TB flags are handled in cpu-exec.c:tb_find_fast(). If I understand > > the SH part correctly, the flags copied from env->flags don't contain > > the privileged mode bits, isn't that in env->sr & SR_MD? > > > > Right. In > target-sh4/translate.c:get_intermediate_code_internal(), > the value env->sr & SR_MD used to set ctx->memidx. > We can use ctx->memidx to check the privileged mode at translation time, > and can use env->sr to check at execution time. Both implementation > can be done, I guess. But ctx->memidx value will be accurate only if the TB flags contain the SR_MD bit. Then if the bit is different, a new TB will be generated using ctx-memidx that reflects the SR_MD bit. > > Alternatively, the check could be made at execution time, but that's > > less efficient. > > > > If QEMU means *quick* emulator, more efficient way seems proper, > so my current opinion is that privilege check should be done at > translation time. Right.