Re: [Xen-devel] Ubuntu 16.04.1 LTS kernel 4.4.0-57 over-allocation and xen-access fail

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 01/10/2017 06:40 PM, Tamas K Lengyel wrote:
>     > (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.
> 
>     I understand your point, however the alternative is potential lack of
>     availability to monitor which is arguably a more severe problem. _Any_
>     guest could choose to do what this Ubuntu 16.04 guest does, and then
>     connecting to the guest via vm_event can only be done once.
> 
> 
> IMHO in that case you should implement your own internal version of this
> function to fall back to instead of forcing all tools to go down this
> path. The requirements to do that in your own tool are accessible so
> there is no need to push that into libxc.

Obviously I won't send a patch you're against as co-maintainer of
vm_event, however looking at my version of xc_vm_event_enable() (from
Xen 4.6), it's calling xc_vm_event_control() which is not publicly
accesible - so going my own way would in this case still require libxc
modifications.

We could also add another parameter to xc_vm_event_enable(), for example
"bool remove_page_from_guest_physmap" to control this behaviour, which
would change the API - or leave the current API alone and add
xc_vm_event_control_remap() or something to that effect.

But in any case I don't see how any of this can be achieved with zero
libxc modifications.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel