From: Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] SH4: Privilege check for instructions
Date: Sun, 14 Sep 2008 19:27:51 +0900 [thread overview]
Message-ID: <48CCE727.7000203@juno.dti.ne.jp> (raw)
In-Reply-To: <f43fc5580809132334y22a898eena74ee34c39c8886c@mail.gmail.com>
Thank you for the comment!
Blue Swirl wrote:
> On 9/14/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> 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.
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 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.
> 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.
Anyway I'm not yet sure about QEMU internal.
More comments will be welcome!
Best Regards,
Shin-ichiro KAWASAKI
next prev parent reply other threads:[~2008-09-14 10:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-14 4:04 [Qemu-devel] [PATCH] SH4: Privilege check for instructions Shin-ichiro KAWASAKI
2008-09-14 6:34 ` Blue Swirl
2008-09-14 10:27 ` Shin-ichiro KAWASAKI [this message]
2008-09-14 11:26 ` Blue Swirl
2008-09-15 1:38 ` Shin-ichiro KAWASAKI
2008-09-15 8:49 ` Aurelien Jarno
2008-09-15 15:19 ` Blue Swirl
2008-09-16 16:44 ` Shin-ichiro KAWASAKI
2008-09-16 18:19 ` Blue Swirl
2008-09-17 1:20 ` Shin-ichiro KAWASAKI
2008-09-17 14:42 ` Paul Mundt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48CCE727.7000203@juno.dti.ne.jp \
--to=kawasaki@juno.dti.ne.jp \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).