Re: [PATCH v2] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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.
> > <scratchis his head> 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