On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru <rcojoc...@bitdefender.com>
wrote:
> >>> What I meant was taking out this call:
> >>>
> >>> /* Remove the ring_pfn from the guest's physmap */
> >>> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
> >>> &ring_pfn);
> >>> if ( rc1 != 0 )
> >>> PERROR("Failed to remove ring page from guest physmap");
> >>>
> >>> To leave the frame in the guest physmap. The issue is fundamentally
> >>> that after this frame has been taken out, something kicks the VM to
> >>> realise it has an extra frame of balloonable space, which it clearly
> >>> compensates for.
> >>>
> >>> You can work around the added attack surface by marking it RO in EPT;
> >>> neither Xen's nor dom0's mappings are translated via EPT, so they can
> >>> still make updates, but the guest won't be able to write to it.
> >>>
> >>> I should say that this is all a gross hack, and is in desperate need of
> >>> a proper API to make rings entirely outside of the gfn space, but this
> >>> hack should work for now.
> >> Thanks! So far, it seems to work like a charm like this:
> >
> > Great.
> >
> >>
> >> diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
> >> index 2fef96a..5dd00a6 100644
> >> --- a/tools/libxc/xc_vm_event.c
> >> +++ b/tools/libxc/xc_vm_event.c
> >> @@ -130,9 +130,17 @@ void *xc_vm_event_enable(xc_interface *xch,
> domid_t
> >> domain_id, int param,
> >> }
> >>
> >> /* Remove the ring_pfn from the guest's physmap */
> >> + /*
> >> rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
> >> &ring_pfn);
> >> if ( rc1 != 0 )
> >> PERROR("Failed to remove ring page from guest physmap");
> >> + */
> >> +
> >> + if ( xc_set_mem_access(xch, domain_id, XENMEM_access_r, mmap_pfn,
> 1) )
> >> + {
> >> + PERROR("Could not set ring page read-only\n");
> >> + goto out;
> >> + }
> >>
> >> out:
> >> saved_errno = errno;
> >>
> >> Should I send this as a patch for mainline as well?
> >
> > Probably a good idea, although I would include a code comment explaining
> > what is going on, because this is subtle if you don't know the context.
>
> Will do, I'll send a patch out as soon as we've done a few more rounds
> of testing.
>
(replying to all): I'm not in favor of this patch mainly because it is not
stealthy. A malicious kernel could easily track what events are being sent
on the ring. With DRAKVUF I could work around this using altp2m
pfn-remapping, but for other tools this is can be a serious information
leak.
Tamas
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
