linux-kernel - Re: [RFC PATCH 1/3] add generic hypercall support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 06 May 2009 08:52:20 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Gregory Haskins <ghaskins@...ell.com>
CC:	linux-kernel@...r.kernel.org, kvm@...r.kernel.org, avi@...hat.com
Subject: Re: [RFC PATCH 1/3] add generic hypercall support

Gregory Haskins wrote:
> We add a generic hypercall() mechanism for use by IO code which is
> compatible with a variety of hypervisors, but which prefers to use
> hypercalls over other types of hypervisor traps for performance and/or
> feature reasons.
>
> For instance, consider an emulated PCI device in KVM.  Today we can chose
> to do IO over MMIO or PIO infrastructure, but they each have their own
> distinct disadvantages:
>
> *) MMIO causes a page-fault, which must be decoded by the hypervisor and is
>    therefore fairly expensive.
>
> *) PIO is more direct than MMIO, but it poses other problems such as:
>       a) can have a small limited address space (x86 is 2^16)
>       b) is a narrow-band interface (one 8, 16, 32, 64 bit word at a time)
>       c) not available on all archs (PCI mentions ppc as problematic) and
>          is therefore recommended to avoid.
>
> Hypercalls, on the other hand, offer a direct access path like PIOs, yet
> do not suffer the same drawbacks such as a limited address space or a
> narrow-band interface.  Hypercalls are much more friendly to software
> to software interaction since we can pack multiple registers in a way
> that is natural and simple for software to utilize.
>   

No way.  Hypercalls are just about awful because they cannot be 
implemented sanely with VT/SVM as Intel/AMD couldn't agree on a common 
instruction for it.  This means you either need a hypercall page, which 
I'm pretty sure makes transparent migration impossible, or you need to 
do hypercall patching which is going to throw off attestation.

If anything, I'd argue that we shouldn't use hypercalls for anything in 
KVM because it will break run-time attestation.

Hypercalls cannot pass any data either.  We pass data with hypercalls by 
relying on external state (like register state).  It's just as easy to 
do this with PIO. VMware does this with vmport, for instance.  However, 
in general, you do not want to pass that much data with a notification.  
It's better to rely on some external state (like a ring queue) and have 
the "hypercall" act simply as a notification mechanism.

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/