From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls Date: Mon, 11 Jan 2016 13:01:29 -0500 Message-ID: <20160111180129.GA12039@char.us.oracle.com> References: <1452531079-4483-1-git-send-email-andrew.cooper3@citrix.com> <20160111171106.GM10641@char.us.oracle.com> <5693ED57.5010705@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5693ED57.5010705@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Stefano Stabellini , Ian Campbell , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org On Mon, Jan 11, 2016 at 05:58:47PM +0000, Andrew Cooper wrote: > On 11/01/16 17:11, Konrad Rzeszutek Wilk wrote: > > On Mon, Jan 11, 2016 at 04:51:19PM +0000, Andrew Cooper wrote: > >> Currently, hypercalls issued from HVM userspace will unconditionally fail with > >> -EPERM. > >> > >> This is inflexible, and a guest may wish to allow userspace to make > >> hypercalls. > >> > >> Introduce HVMOP_set_hypercall_dpl which allows the guest to alter the > >> permissions check for hypercalls. It behaves exactly like the dpl field for > >> GDT/LDT/IDT entries. > > > > Could you explain a bit of the use-case? > > My specific usecase, > http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=shortlog;h=refs/heads/wip-traps-v0.1 > > It isn't quite ready for formal release yet. > > > As in why the ioctl via the kernel is no good? > > Who says Linux is running? What else would there be :-) > > Hopefully answered in > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01155.html Yes. If you could add it in the commit description that would be most helpful. Thank you! > > > > >> As the dpl is initialised to 0, hypercalls are restricted to cpl0 code until > >> the OS explicitly chooses an alternative. > > So we enable to make hypercalls but then we don't allow > > it unless it is in ring 0? > > Correct. Hypercalls are by default limited to cpl0 (i.e. the existing > behaviour), but guests can use this new hypercall to change the > permission check. > > Naturally, you have to be sufficiently privileged to make this hypercall > in the first place, so only the kernel may opt to relax the check. Right. Sorry I somehow had in mind that this hypercall would be made by the toolstack which is why I was confused. > > ~Andrew