Re: [Xen-devel] [VMI] How to add support for MOV-TO-DRx events ?

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, May 9, 2019 at 4:54 PM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>
> On 09/05/2019 23:34, Tamas K Lengyel wrote:
> > On Thu, May 9, 2019 at 3:50 PM Razvan Cojocaru
> > <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> >> On 5/10/19 12:31 AM, Andrew Cooper wrote:
> >>> What we'll have to do is end up in a position where we can have some
> >>> real %dr settings given by the VMI agent, and some shadow %dr settings
> >>> which the guest interacts with.  Also I should warn you at this point
> >>> that, because of how the registers work, It will not be possible to have
> >>> guest-shadowed %dr functioning at the same time as VMI-provided %dr
> >>> settings.
> >>>
> >>> I guess the main usecase here is simply hiding from the guest kernel
> >>> that debugging activities are in use, and we are ok to break the real
> >>> use of gdb/other inside the guest?  Razvan/Tamas: As your the
> >>> maintainers, it is your call, ultimately.
> >> What worries me here is that in that case it becomes easier for a rogue
> >> application inside the guest to figure out that the guest's being
> >> monitored, if I understand things correctly.
> >>
> >> Of course, a dom0 introspection agent may choose to simply not subscribe
> >> to DR events, and thus not alter the current flow at all, which makes
> >> things better.
> > I agree, ideally none of the VMI events should alter the guests'
> > ability to do anything it normally can and the VMI events should only
> > add overhead (and of course the cache side-effects that are
> > detectable). That said, since the usecase for Mathieu is one where he
> > can live with the guest not being able to run a debugger, I would
> > still accept the patch as long as there is an explicit comment
> > documenting its limitation. We can worry about figuring out how to
> > make the event transparent iff that becomes needed for some other
> > usecase.
>
> It is not possible to share use of the debugging facilities,
> irrespective of whether you wish to hide the sharing from the guest kernel.
>
> Depending on exactly what the VMI agent wants to do, it could see about
> context switching the hidden-active settings behind the back of the
> kernel, e.g. if one process is debugging itself, but the VMI agent wants
> to transparently debug another.
>
> However, if both the guest and VMI agent want to use the debugging
> facilities, one is going to have to relinquish use.  It should be
> possible for the VMI agent to cleanly detach its hidden settings.

Right, like relinquishing the hardware breakpoints and switching to
software breakpoints instead.

> Either way, everything comes down to what behaviour is wanted to start with.

As I said, I think adding that monitoring capability is fine as long
as its limitation is clearly documented.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel