From: Julien Grall <julien.grall@arm.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Paul Durrant <Paul.Durrant@citrix.com>,
Xen-devel <xen-devel@lists.xen.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 3/5] x86/hvm: Make HVM_PARAM_{STORE, CONSOLE}_EVTCHN read-only to the guest
Date: Thu, 6 Sep 2018 18:28:11 +0100 [thread overview]
Message-ID: <8a62dcf3-1767-9eb1-091c-eef35287b252@arm.com> (raw)
In-Reply-To: <8b17a884-035f-bd68-62c4-3bcaad9c5277@citrix.com>
On 06/09/18 16:29, Andrew Cooper wrote:
> On 06/09/18 10:16, Paul Durrant wrote:
>>> -----Original Message-----
>>> From: Andrew Cooper [mailto:andrew.cooper3@citrix.com]
>>> Sent: 05 September 2018 19:12
>>> To: Xen-devel <xen-devel@lists.xen.org>
>>> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Jan Beulich
>>> <JBeulich@suse.com>; Wei Liu <wei.liu2@citrix.com>; Roger Pau Monne
>>> <roger.pau@citrix.com>; Paul Durrant <Paul.Durrant@citrix.com>; Stefano
>>> Stabellini <sstabellini@kernel.org>; Julien Grall <julien.grall@arm.com>
>>> Subject: [PATCH 3/5] x86/hvm: Make
>>> HVM_PARAM_{STORE,CONSOLE}_EVTCHN read-only to the guest
>>>
>>> These values are set by the toolstack for each create/restore operation, and
>>> bound by xen{store,console}d before the the guest starts running.
>>>
>>> A guest has no reason to modify them at all, and the matching *_PFN
>>> parameters
>>> are already read-only. Adjust the *_EVTCHN permissions to be consistent.
>> Unfortunately this patch will break the Windows PV driver function here:
>>
>> http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenbus.git;a=blob;f=src/xenbus/evtchn.c;hb=HEAD#l1037
>>
>> Unfortunately the values really do change across a reset. It would be possible to use volatile (disappear on reboot) registry keys to store the updated values instead but I don't really see any harm in allowing the guest to update the values to be correct, unless we want to change Xen to do the job so the guest doesn't have to go through this dance.
>
> :( Everything is terrible.
>
> This is a general problem, not x86 specific, so I'll drop this patch and
> make a similar adjustment to the ARM one.
I am a bit confused. I would have thought this was updated by the
toolstack at reset. So why would the guest update them?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-09-06 17:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 18:11 [PATCH 0/5] xen: Fixes and improvements to HVM_PARAM handling Andrew Cooper
2018-09-05 18:12 ` [PATCH 1/5] x86/hvm: Switch hvm_allow_get_param() to use a whitelist Andrew Cooper
2018-09-06 8:56 ` Paul Durrant
2018-09-06 15:21 ` Andrew Cooper
2018-09-07 6:30 ` Jan Beulich
2018-09-07 8:55 ` Jan Beulich
2018-09-07 18:18 ` Andrew Cooper
2018-09-10 9:41 ` Jan Beulich
2018-09-07 15:42 ` Roger Pau Monné
2018-09-05 18:12 ` [PATCH 2/5] x86/hvm: Switch hvm_allow_set_param() " Andrew Cooper
2018-09-06 9:08 ` Paul Durrant
2018-09-06 15:27 ` Andrew Cooper
2018-09-07 16:01 ` Roger Pau Monné
2018-09-07 18:13 ` Andrew Cooper
2018-09-10 14:28 ` Roger Pau Monné
2018-09-05 18:12 ` [PATCH 3/5] x86/hvm: Make HVM_PARAM_{STORE, CONSOLE}_EVTCHN read-only to the guest Andrew Cooper
2018-09-06 9:16 ` Paul Durrant
2018-09-06 15:29 ` Andrew Cooper
2018-09-06 17:28 ` Julien Grall [this message]
2018-09-07 16:19 ` Paul Durrant
2018-09-07 16:03 ` Roger Pau Monné
2018-09-05 18:12 ` [PATCH 4/5] x86/hvm: Misc non-functional cleanup to the HVM_PARAM infrastructure Andrew Cooper
2018-09-06 9:26 ` Paul Durrant
2018-09-07 9:08 ` Jan Beulich
2018-09-07 16:23 ` Roger Pau Monné
2018-09-05 18:12 ` [PATCH 5/5] xen/ARM: Restrict access to most HVM_PARAM's Andrew Cooper
2018-09-06 9:29 ` Paul Durrant
2018-09-06 10:36 ` Julien Grall
2018-09-06 10:40 ` Andrew Cooper
2018-09-06 10:43 ` Paul Durrant
2018-09-06 10:40 ` Paul Durrant
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=8a62dcf3-1767-9eb1-091c-eef35287b252@arm.com \
--to=julien.grall@arm.com \
--cc=JBeulich@suse.com \
--cc=Paul.Durrant@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wei.liu2@citrix.com \
--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).