qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Bin Meng <bmeng.cn@gmail.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	qemu-devel@nongnu.org
Cc: Bin Meng <bin.meng@windriver.com>
Subject: Re: [PATCH] target/i386: seg_helper: Correct segement selector nullification in the RET/IRET helper
Date: Thu, 12 Nov 2020 12:48:14 +0100	[thread overview]
Message-ID: <15131296-512a-f70c-5e9e-d422b3b26136@redhat.com> (raw)
In-Reply-To: <1603361762-43062-1-git-send-email-bmeng.cn@gmail.com>

On 22/10/20 12:16, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
> 
> Per the SDM, when returning to outer privilege level, for segment
> registers (ES, FS, GS, and DS) if the check fails, the segment
> selector becomes null, but QEMU clears the base/limit/flags as well
> as nullifying the segment selector, which should be a spec violation.
> 
> Real hardware seems to be compliant with the spec, at least on one
> Coffee Lake board I tested.

This is all quite messy in QEMU; for performance reasons, it never even 
checks the flags on memory accesses, only on selector loads.  One way to 
fix it would be to define five extra hflags bits that copy the P bit of 
DS/ES/SS/FS/GS.  gen_lea_v_seg checks if the hflag is clear, and if so 
it generates a #GP or #SS.

Regarding your patch, I think at least the segment should be made 
"unusable".  On Intel processors there is an internal "unusable" flag, 
on AMD and in QEMU, equivalently, the P bit would be cleared in the 
flags.  As far as I know the difference is only visible with VMX.

That is, you'd need something like this:

         cpu_x86_load_seg_cache(env, seg_reg, 0,
                                env->segs[seg_reg].base,
                                env->segs[seg_reg].limit,
                                env->segs[seg_reg].flags & ~DESC_P_MASK);

Thanks,

Paolo

> 
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
> 
>   target/i386/seg_helper.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/target/i386/seg_helper.c b/target/i386/seg_helper.c
> index be88938..d8766d8 100644
> --- a/target/i386/seg_helper.c
> +++ b/target/i386/seg_helper.c
> @@ -2108,7 +2108,10 @@ static inline void validate_seg(CPUX86State *env, int seg_reg, int cpl)
>       if (!(e2 & DESC_CS_MASK) || !(e2 & DESC_C_MASK)) {
>           /* data or non conforming code segment */
>           if (dpl < cpl) {
> -            cpu_x86_load_seg_cache(env, seg_reg, 0, 0, 0, 0);
> +            cpu_x86_load_seg_cache(env, seg_reg, 0,
> +                                   env->segs[seg_reg].base,
> +                                   env->segs[seg_reg].limit,
> +                                   env->segs[seg_reg].flags);
>           }
>       }
>   }
> 




      parent reply	other threads:[~2020-11-12 11:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-22 10:16 [PATCH] target/i386: seg_helper: Correct segement selector nullification in the RET/IRET helper Bin Meng
2020-11-02  8:20 ` Bin Meng
2020-11-12  6:33   ` Bin Meng
2020-11-12 11:48 ` Paolo Bonzini [this message]

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=15131296-512a-f70c-5e9e-d422b3b26136@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=bmeng.cn@gmail.com \
    --cc=ehabkost@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).