From: "Jan Beulich" <JBeulich@suse.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: Andrei LUTAS <vlutas@bitdefender.com>,
Tamas K Lengyel <tamas@tklengyel.com>,
Wei Liu <wei.liu2@citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Mihai Dontu <mdontu@bitdefender.com>,
Kevin Tian <kevin.tian@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
aisaila@bitdefender.com,
xen-devel <xen-devel@lists.xenproject.org>,
Anshul Makkar <anshul.makkar@citrix.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults
Date: Fri, 23 Nov 2018 02:07:59 -0700 [thread overview]
Message-ID: <5BF7C36F02000078001FF3E1@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <838191050200006B34861ACF@prv1-mh.provo.novell.com>
>>> On 22.11.18 at 19:24, <rcojocaru@bitdefender.com> wrote:
> _However_, please picture an instruction that both writes into a page P1
> we're interested in, _and_ causes a write into a read-only page-walk
> related page P2. Emulating the current instruction, as the upstream
> patch does, does eliminate the vm_event caused by writing into P2, but
> with the unfortunate side-effect of losing a potentially critical event
> for the write into P1.
>
> What this patch attempts to do is to mark P1 rwx (so allow the write),
> then put the faulting VCPU into singlestep mode, then restore the
> restrictions after it has finished single stepping. By now it's obvious
> why all the other VCPUs need to be paused: one of them might do a
> malicious write into P1 that silently succeeds (since the EPT is shared
> among all VCPUs - putting altp2m aside for a moment). We don't want that.
I think this all goes into the fundamentally wrong direction. If lost
events during emulation are your issue, then let's make sure
emulation paths trigger the same events hardware would.
With a sufficiently complete insn emulator, single-stepping should
not be needed at all imo. Granted we're not quite there yet with
the emulator, but we've made quite a bit of progress. As before,
if there are particular instructions you know of that the emulator
doesn't handle yet, please keep pointing these out. Last I know
were some AVX move instructions, which have long been
implemented.
> Alternatively, we'd be happy with simply being able to set the relevant
> A/D bits in the pages touched by the page walk, but after lenghty
> negotiations that can be found in the xen-devel archives we were unable
> to find a safe, architecturally correct way of doing that.
Hmm, I don't recall that we had settled that this would be entirely
impossible, but then again - as per above - this as well was only
curing symptoms rather than the cause.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-11-23 9:08 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-16 10:06 [PATCH v1] x86/hvm: Generic instruction re-execution mechanism for execute faults Alexandru Stefan ISAILA
2018-11-16 17:04 ` Roger Pau Monné
2018-11-19 13:30 ` Alexandru Stefan ISAILA
2018-11-19 14:26 ` Jan Beulich
2018-11-19 15:08 ` Roger Pau Monné
2018-11-19 15:56 ` Alexandru Stefan ISAILA
2018-11-21 9:56 ` Roger Pau Monné
2018-11-21 10:28 ` Alexandru Stefan ISAILA
2018-11-21 11:41 ` Roger Pau Monné
2018-11-21 12:00 ` Alexandru Stefan ISAILA
2018-11-19 13:33 ` Jan Beulich
2018-11-21 18:55 ` Razvan Cojocaru
2018-11-22 9:50 ` Alexandru Stefan ISAILA
2018-11-22 10:00 ` Jan Beulich
2018-11-22 10:07 ` Roger Pau Monné
2018-11-22 10:05 ` Roger Pau Monné
2018-11-22 10:14 ` Razvan Cojocaru
2018-11-22 10:58 ` Roger Pau Monné
2018-11-22 12:48 ` Razvan Cojocaru
2018-11-22 14:49 ` Roger Pau Monné
2018-11-22 15:25 ` Razvan Cojocaru
2018-11-22 15:37 ` Roger Pau Monné
2018-11-22 16:52 ` Razvan Cojocaru
2018-11-22 17:08 ` Roger Pau Monné
2018-11-22 18:24 ` Razvan Cojocaru
2018-11-23 8:54 ` Roger Pau Monné
[not found] ` <59739FBC020000C234861ACF@prv1-mh.provo.novell.com>
[not found] ` <F553A58C020000AB0063616D@prv1-mh.provo.novell.com>
[not found] ` <4D445A680200003E34861ACF@prv1-mh.provo.novell.com>
[not found] ` <DAD49D5A020000780063616D@prv1-mh.provo.novell.com>
[not found] ` <5400A6CB0200003634861ACF@prv1-mh.provo.novell.com>
[not found] ` <203C1A92020000400063616D@prv1-mh.provo.novell.com>
[not found] ` <0DF3BC62020000E934861ACF@prv1-mh.provo.novell.com>
[not found] ` <C6A2E442020000640063616D@prv1-mh.provo.novell.com>
[not found] ` <6EEA58AB020000EA34861ACF@prv1-mh.provo.novell.com>
2018-11-27 10:31 ` Razvan Cojocaru
2018-11-27 11:32 ` Roger Pau Monné
2018-11-27 11:45 ` Razvan Cojocaru
2018-11-27 11:59 ` Andrew Cooper
2018-11-27 12:12 ` Razvan Cojocaru
2018-12-19 16:49 ` Alexandru Stefan ISAILA
2018-12-19 17:40 ` Roger Pau Monné
2018-12-20 14:37 ` Alexandru Stefan ISAILA
[not found] ` <838191050200006B34861ACF@prv1-mh.provo.novell.com>
2018-11-23 9:07 ` Jan Beulich [this message]
2018-11-27 10:49 ` Razvan Cojocaru
2018-11-27 11:28 ` Jan Beulich
2018-11-27 11:44 ` Razvan Cojocaru
2019-05-13 13:58 ` Razvan Cojocaru
2019-05-13 13:58 ` [Xen-devel] " Razvan Cojocaru
2019-05-13 14:06 ` Jan Beulich
2019-05-13 14:06 ` [Xen-devel] " Jan Beulich
2019-05-13 14:15 ` Razvan Cojocaru
2019-05-13 14:15 ` [Xen-devel] " Razvan Cojocaru
2019-05-14 13:47 ` Razvan Cojocaru
2019-05-14 13:47 ` [Xen-devel] " Razvan Cojocaru
2019-05-14 14:16 ` Jan Beulich
2019-05-14 14:16 ` [Xen-devel] " Jan Beulich
2019-05-14 14:20 ` Razvan Cojocaru
2019-05-14 14:20 ` [Xen-devel] " Razvan Cojocaru
[not found] ` <A31948D30200007D0063616D@prv1-mh.provo.novell.com>
2018-11-23 9:10 ` Jan Beulich
[not found] ` <9B05ED9E020000C434861ACF@prv1-mh.provo.novell.com>
[not found] ` <626A217B020000C50063616D@prv1-mh.provo.novell.com>
[not found] ` <0D3C56BA0200004834861ACF@prv1-mh.provo.novell.com>
2018-12-20 9:07 ` Jan Beulich
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=5BF7C36F02000078001FF3E1@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=aisaila@bitdefender.com \
--cc=andrew.cooper3@citrix.com \
--cc=anshul.makkar@citrix.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=mdontu@bitdefender.com \
--cc=rcojocaru@bitdefender.com \
--cc=roger.pau@citrix.com \
--cc=tamas@tklengyel.com \
--cc=vlutas@bitdefender.com \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.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).