[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Hypercall by DomU Application





On Thu, Oct 27, 2011 at 5:43 AM, Tim Deegan <tim@xxxxxxx> wrote:
At 20:16 -0500 on 25 Oct (1319573807), Srujan Kotikela wrote:
> Hi,
>
> I am working on a security architecture. In this architecture, the
> application in DomU has to communicate directly with the hypervisor. But as
> I can see, the xen architecture allows only DomU kernel to raise a
> hypercall. I am planning to enable application to communicate with xen
> directly. I am assuming, setting up a trap gate with Ring-3 access should do
> the trick. I have few questions regarding this.
>
> Is my idea feasible? ==> (  _set_gate(idt_table+HYPERCALL_VECTOR, 15, 3,
> &hypercall); )

Seems like it would be easy to find out. :)

> Are there any security/performance/functional implications with this
> approach?

Well, it totally undermines the security of the kernel if the
application can get the hypervisor to alter memory (since the
hypervisor doesn't know about the kernel's datastructures or policies)
but if you're very restrictive about what hypercalls can be called frum
user-mode, it should be OK.

One thing to look out for is making sure that the hypercall arguments
are actually mapped properly when the call happens (since the kernel
controls paging).

Tim.

Hi,

I am able to successfuly invoke a hypercall from user level just by using int $0x82 from the user level. 
I need this only for specific (custom) hypercalls. I was wondering how could I filter which hypercalls to be invoked from ring-3.

Filtering at the user level is straight forward but have to trust the user (poor design). 

I was wondering if I can somehow check the DPL of the caller before the control goes to the hypercall handler from the hypercall_vector?

~ SDK

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.