Re: [PATCH/PFC 0/2] s390 host support

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Carsten Otte wrote:
>
>
>> Can one do the equivalent of a futex wakeup from the kernel easily?
> No, we did not have the need to do that. Now that you mention it, we'd 
> want to move interprocessor signal handling into the kernel anyway for 
> performance reasons. That would rise the need to wake up from kernel. 
> The other way round, how do you intend to wake a thread that uses 
> poll() or similar from userspace?
>

Write to a pipe, or send a signal (signals are quite fast if you mask 
them in userspace and use ppoll()).

>> Nested page tables/extended page tables also provide this facility, 
>> with some caveats:
>>
>> - on 32-bit hosts (or 64-bit hosts with 32-bit userspace), host 
>> userspace virtual address space is not enough to contain the guest 
>> physical address space.
>> - there is no way to protect the host userspace from the guest
>> - some annoying linker scripts need to be used to compile the host 
>> userspace to move it out of the guest userspace area, making it more 
>> difficult to write kvm userspace
>>
>> I think there's a way to work around these issues on 64-bit npt 
>> hardware: allocate a pgd entry (at a non-zero offset) to hold guest 
>> physical memory, and copy this pgd entry into a guest-only pgd at 
>> offset zero.
>>
>> Of course, there are many millions of non-npt/ept processors out 
>> there, and we can't leave them out in the cold, so we'll have to work 
>> something out for classical shadow page tables.
> No, of course not. The nested pagetable approach sounds neat to me. 
> Does'nt
> the fact that there will be no security barrier between guest 
> userspace and virtual machine require running kvm as non privileged 
> user in the end?

The trick I mentioned (copying a pgd entry) means:

- guest physical and host userspace are different (have different pgds)
- guest physical (offset 0) is aliased to host userspace (offset $bignum)
- guest address space is limited to 2^(12+9*3)
- the pte dirty and accessed bits are shared

so guest userspace is not exposed, but the guest ptes _are_ shared.

In a way, this is similar to shared memory, if shared page tables are 
ever implemented.  Think of a shared memory segment mapped at two 
different offsets, but aligned at a pud boundary so everything below the 
pgd entry is sharable.

>
> Our implementation does use action bits preseted to sys_s390host_sie 
> to update the hardware control blocks for the virutal machine. The 
> hardware control blocks would be mapped read-only to user address 
> space. This way, the kernel can enforce the user not to mess things 
> up, which allows to run non-privileged user code (userid johndoe 
> instead of root). Would this approach be reasonable on x86 too?

Allowing the guest to hack the host userspace exposes the rest of the 
user's processes to a malicious guest, and allows the guest to open 
network connections through the host, no?

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/