linux-kernel - Re: [Qemu-devel] [RFC] Next gen kvm api

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:	Thu, 16 Feb 2012 08:46:19 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Gleb Natapov <gleb@...hat.com>
CC:	KVM list <kvm@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...hat.com>, Rusty Russell <rusty@...abs.org>,
	qemu-devel <qemu-devel@...gnu.org>
Subject: Re: [Qemu-devel] [RFC] Next gen kvm api

On 02/16/2012 02:57 AM, Gleb Natapov wrote:
> On Wed, Feb 15, 2012 at 03:59:33PM -0600, Anthony Liguori wrote:
>> On 02/15/2012 07:39 AM, Avi Kivity wrote:
>>> On 02/07/2012 08:12 PM, Rusty Russell wrote:
>>>>> I would really love to have this, but the problem is that we'd need a
>>>>> general purpose bytecode VM with binding to some kernel APIs.  The
>>>>> bytecode VM, if made general enough to host more complicated devices,
>>>>> would likely be much larger than the actual code we have in the kernel now.
>>>>
>>>> We have the ability to upload bytecode into the kernel already.  It's in
>>>> a great bytecode interpreted by the CPU itself.
>>>
>>> Unfortunately it's inflexible (has to come with the kernel) and open to
>>> security vulnerabilities.
>>
>> I wonder if there's any reasonable way to run device emulation
>> within the context of the guest.  Could we effectively do something
>> like SMM?
>>
>> For a given set of traps, reflect back into the guest quickly
>> changing the visibility of the VGA region. It may require installing
>> a new CR3 but maybe that wouldn't be so bad with VPIDs.
>>
> What will it buy us? Surely not speed. Entering a guest is not much
> (if at all) faster than exiting to userspace and any non trivial
> operation will require exit to userspace anyway,

You can emulate the PIT/RTC entirely within the guest using kvmclock which 
doesn't require an additional exit to get the current time base.

So instead of:

1) guest -> host kernel
2) host kernel -> userspace
3) implement logic using rdtscp via VDSO
4) userspace -> host kernel
5) host kernel -> guest

You go:

1) guest -> host kernel
2) host kernel -> guest (with special CR3)
3) implement logic using rdtscp + kvmclock page
4) change CR3 within guest and RETI to VMEXIT source RIP

Same basic concept as PS/2 emulation with SMM.

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/