From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Tim Deegan <tim@xen.org>, Xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches
Date: Thu, 1 Jun 2017 12:22:34 +0100 [thread overview]
Message-ID: <0614feaa-5ea0-adce-106c-dc4745b4835d@citrix.com> (raw)
In-Reply-To: <59300DBD020000780015EA20@prv-mh.provo.novell.com>
On 01/06/17 11:51, Jan Beulich wrote:
>>>> On 01.06.17 at 12:19, <andrew.cooper3@citrix.com> wrote:
>> On 29/05/17 10:15, Jan Beulich wrote:
>>>>>> On 29.05.17 at 11:03, <andrew.cooper3@citrix.com> wrote:
>>>> On 29/05/2017 09:58, Jan Beulich wrote:
>>>>>>>> On 26.05.17 at 19:03, <andrew.cooper3@citrix.com> wrote:
>>>>>> --- a/xen/arch/x86/mm/guest_walk.c
>>>>>> +++ b/xen/arch/x86/mm/guest_walk.c
>>>>>> @@ -114,22 +114,18 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain
>> *p2m,
>>>>>> ASSERT(!(walk & PFEC_implicit) ||
>>>>>> !(walk & (PFEC_insn_fetch | PFEC_user_mode)));
>>>>>>
>>>>>> - /*
>>>>>> - * PFEC_insn_fetch is only used as an input to pagetable walking if NX
>> or
>>>>>> - * SMEP are enabled. Otherwise, instruction fetches are
>> indistinguishable
>>>>>> - * from data reads.
>>>>>> - *
>>>>>> - * This property can be demonstrated on real hardware by having NX and
>>>>>> - * SMEP inactive, but SMAP active, and observing that EFLAGS.AC
>> determines
>>>>>> - * whether a pagefault occures for supervisor execution on user
>> mappings.
>>>>>> - */
>>>>>> - if ( !(guest_nx_enabled(v) || guest_smep_enabled(v)) )
>>>>>> - walk &= ~PFEC_insn_fetch;
>>>>>> -
>>>>>> perfc_incr(guest_walk);
>>>>>> memset(gw, 0, sizeof(*gw));
>>>>>> gw->va = va;
>>>>>> - gw->pfec = walk & (PFEC_insn_fetch | PFEC_user_mode | PFEC_write_access);
>>>>>> + gw->pfec = walk & (PFEC_user_mode | PFEC_write_access);
>>>>>> +
>>>>>> + /*
>>>>>> + * PFEC_insn_fetch is only reported if NX or SMEP are enabled.
>> Hardware
>>>>>> + * still distingueses instruction fetches during determination of
>> access
>>>>>> + * rights.
>>>>>> + */
>>>>>> + if ( guest_nx_enabled(v) || guest_smep_enabled(v) )
>>>>>> + gw->pfec |= (walk & PFEC_insn_fetch);
>>>>>>
>>>>>> #if GUEST_PAGING_LEVELS >= 3 /* PAE or 64... */
>>>>>> #if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
>>>>> Don't you another adjustment to
>>>>>
>>>>> if ( (walk & PFEC_insn_fetch) && (ar & _PAGE_NX_BIT) )
>>>>> /* Requested an instruction fetch and found NX? Fail. */
>>>>> goto out;
>>>>>
>>>>> I can't see anything that would keep _PAGE_NX_BIT out of
>>>>> ar if NX is not enabled.
>>>> _PAGE_NX_BIT is reserved if NX is not enabled, and is accounted for in
>>>> guest_rsvd_bits() in guest_pt.h, and we never hit the access rights logic.
>>> Ah, right. But perhaps worth having a respective ASSERT()
>>> here, at once serving as documentation?
>> I could, but it would feel be out of place. NX being incorrectly set is
>> a translation failure, and by definition, the translation needs to have
>> succeeded before permissions get considered.
>>
>> Would this clarification be acceptable?
>>
>> index 5c6a85b..6d6b454 100644
>> --- a/xen/arch/x86/mm/guest_walk.c
>> +++ b/xen/arch/x86/mm/guest_walk.c
>> @@ -360,8 +360,9 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
>> gw->pfec |= PFEC_page_present;
>>
>> /*
>> - * The pagetable walk has returned a successful translation. Now check
>> - * access rights to see whether the access should succeed.
>> + * The pagetable walk has returned a successful translation (i.e. All
>> + * PTEs are present and have no reserved bits set). Now check access
>> + * rights to see whether the access should succeed.
>> */
> While this perhaps is a worthwhile addition, my original request
> really was to make more visible around the place where it matters
> that the NX bit is part of the reserved ones when NX is off. Hence
> I'm not sure the comment change is worthwhile, and if you dislike
> adding the suggested ASSERT() I won't the patch be left as is.
I presume you means something like you won't mind if the patch is left
as-is?
How about this?
diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 972364f..6055fec 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -356,11 +356,19 @@ guest_walk_tables(struct vcpu *v, struct
p2m_domain *p2m,
gw->pfec |= PFEC_page_present;
/*
- * The pagetable walk has returned a successful translation. Now check
- * access rights to see whether the access should succeed.
+ * The pagetable walk has returned a successful translation (i.e.
All PTEs
+ * are present and have no reserved bits set). Now check access
rights to
+ * see whether the access should succeed.
*/
ar = (ar_and & AR_ACCUM_AND) | (ar_or & AR_ACCUM_OR);
+ /*
+ * Sanity check. If EFER.NX is disabled, _PAGE_NX_BIT is reserved and
+ * should have caused a translation failure before we get here.
+ */
+ if ( ar & _PAGE_NX_BIT )
+ ASSERT(guest_nx_enabled(v));
+
#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
/*
* If all access checks are thus far ok, check Protection Key for 64bit
One problem I have with an ASSERT beside the "if ( (walk &
PFEC_insn_fetch) && (ar & _PAGE_NX_BIT) )" is that it is mid-way through
the permissions checks, rather than at the start, which is likely to get
missed if future access checks get introduced ahead of the protection
key checks.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-06-01 11:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-26 17:03 [PATCH RFC for-4.9 0/2] x86/pagewalk: Further bugfixes to pagetable walking Andrew Cooper
2017-05-26 17:03 ` [PATCH 1/2] Revert "x86/hvm: disable pkeys for guests in non-paging mode" Andrew Cooper
2017-05-29 8:48 ` Jan Beulich
2017-05-31 7:09 ` Han, Huaitong
2017-05-31 7:44 ` Andrew Cooper
2017-05-31 7:56 ` Jan Beulich
2017-05-31 8:06 ` Andrew Cooper
2017-05-31 8:12 ` Jan Beulich
2017-05-31 8:14 ` Han, Huaitong
2017-06-01 2:15 ` Tian, Kevin
2017-05-26 17:03 ` [PATCH 2/2] x86/pagewalk: Fix pagewalk's handling of instruction fetches Andrew Cooper
2017-05-29 8:58 ` Jan Beulich
2017-05-29 9:03 ` Andrew Cooper
2017-05-29 9:15 ` Jan Beulich
2017-06-01 10:19 ` Andrew Cooper
2017-06-01 10:51 ` Jan Beulich
2017-06-01 11:22 ` Andrew Cooper [this message]
2017-06-01 12:06 ` Jan Beulich
2017-06-01 17:55 ` [PATCH RFC for-4.9 0/2] x86/pagewalk: Further bugfixes to pagetable walking Julien Grall
2017-06-01 17:57 ` Andrew Cooper
2017-06-01 18:00 ` Julien Grall
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=0614feaa-5ea0-adce-106c-dc4745b4835d@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=george.dunlap@eu.citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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).