On 01/05/2019 05:22, Tamas K Lengyel wrote: > Currently the gs_shadow value is only cached when the vCPU is being scheduled > out by Xen. Reporting this (usually) stale value through vm_event is > incorrect, > since it doesn't represent the actual state of the vCPU at the time the event > was recorded. This prevents vm_event subscribers from correctly finding kernel > structures in the guest when it is trapped while in ring3. > > Signed-off-by: Tamas K Lengyel <ta...@tklengyel.com> > Cc: Razvan Cojocaru <rcojoc...@bitdefender.com> > Cc: Jan Beulich <jbeul...@suse.com> > Cc: Andrew Cooper <andrew.coop...@citrix.com> > Cc: Wei Liu <wei.l...@citrix.com> > Cc: Roger Pau Monne <roger....@citrix.com> > --- > xen/arch/x86/vm_event.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c > index 51c3493b1d..4464940da7 100644 > --- a/xen/arch/x86/vm_event.c > +++ b/xen/arch/x86/vm_event.c
Actually, come to think of it, the same is true for the SYSENTER details, which by default are read/write to the guest while it is scheduled. As a result, the details reported here will from the last vcpu context switch, and possibly stale. It might be worth introducing a "sync state from hw" hook which collects all the data we intend to pass to the introspection agent. ~Andrew# _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
