From: Paolo Bonzini <pbonzini@redhat.com>
To: "Wu, Feng" <feng.wu@intel.com>,
"Zhang, Yang Z" <yang.z.zhang@intel.com>,
"gleb@redhat.com" <gleb@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [PATCH 3/4] KVM: Add SMAP support when setting CR4
Date: Fri, 28 Mar 2014 15:09:30 +0100 [thread overview]
Message-ID: <5335829A.1060702@redhat.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F001E86B1E@SHSMSX104.ccr.corp.intel.com>
Il 28/03/2014 08:33, Wu, Feng ha scritto:
> In my understanding it is needed, from Intel SDM:
>
> "Every access to a linear address is either a supervisor-mode access
> or a user-mode access. All accesses performed while the current
> privilege level (CPL) is less than 3 are supervisor-mode accesses.
> If CPL = 3, accesses are generally user-mode accesses. However, some
> operations implicitly access system data structures, and the resulting
> accesses to those data structures are supervisor-mode accesses regardless
> of CPL. Examples of such implicit supervisor accesses include the following:
> accesses to the global descriptor table (GDT) or local descriptor table
> (LDT) to load a segment descriptor; accesses to the interrupt descriptor
> table (IDT) when delivering an interrupt or exception; and accesses to the
> task-state segment (TSS) as part of a task switch or change of CPL."
>
> From the above SDM, we can see supervisor-mode access can also
> happen when CPL equals 3.
>
> If CPL < 3, SMAP protections are disabled if EFLAGS.AC = 1. If CPL = 3,
> SMAP applies to all supervisor-mode data accesses (these are implicit
> supervisor accesses) regardless of the value of EFLAGS.AC.
>
> So when we check the value of EFLAGS.AC, we also need to check CPL, since AC
> bit only takes effect when CPL<3.
>
> U==1 means user-mode access are allowed, while !uf means it is a fault
> from Supervisor-mode access, I think both *u* and *uf* cannot reflect the
> value of CPL.
>
> Correct me if I am wrong. Thanks a lot!
You're right!
Paolo
next prev parent reply other threads:[~2014-03-28 14:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-27 12:25 [PATCH 0/4] KVM: enable Intel SMAP for KVM Feng Wu
2014-03-27 11:50 ` Paolo Bonzini
2014-03-27 17:52 ` H. Peter Anvin
2014-03-27 12:25 ` [PATCH 1/4] KVM: expose SMAP feature to guest Feng Wu
2014-03-27 12:25 ` [PATCH 2/4] KVM: Remove SMAP bit from CR4_RESERVED_BITS Feng Wu
2014-03-27 12:25 ` [PATCH 3/4] KVM: Add SMAP support when setting CR4 Feng Wu
2014-03-27 11:46 ` Paolo Bonzini
2014-03-28 5:47 ` Zhang, Yang Z
2014-03-28 6:23 ` Paolo Bonzini
2014-03-28 7:33 ` Wu, Feng
2014-03-28 14:09 ` Paolo Bonzini [this message]
2014-03-28 9:35 ` Wu, Feng
2014-03-27 12:25 ` [PATCH 4/4] KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode Feng Wu
2014-03-27 16:14 ` Jan Kiszka
2014-03-28 0:41 ` Wu, Feng
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=5335829A.1060702@redhat.com \
--to=pbonzini@redhat.com \
--cc=feng.wu@intel.com \
--cc=gleb@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=yang.z.zhang@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.