linux-kernel - Re: Re: Re: Re: Re: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC offset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 30 Nov 2012 10:36:43 +0900
From:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
To:	Marcelo Tosatti <mtosatti@...hat.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	David Sharp <dhsharp@...gle.com>,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, Joerg Roedel <joerg.roedel@....com>,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Ingo Molnar <mingo@...hat.com>, Avi Kivity <avi@...hat.com>,
	yrl.pp-manager.tt@...achi.com,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Re: Re: Re: Re: Re: Re: [RFC PATCH 0/2] kvm/vmx: Output TSC
 offset

Hi Marcelo,

>>> Can you please write a succint but complete description of the method
>>> so it can be verified?
>>
>> Sure.
>>
>> - Prerequisite
>> 1. the host TSC is synchronized and stable.
>> 2. kvm_write_tsc_offset events include previous and next TSC offset
>>     values.
>> 3. Every event's trace_clock is TSC.
>>
>> - Assumption for the sake of ease
>> 1. One VCPU
>> 2. The guest executes no write_tsc or write_tsc only once.
>>
>> - Configuration
>> 1. On the host, kvm_exit/entry events are recorded in the buffer A and
>>     kvm_write_tsc_offset events are recorded in the buffer B.
>> 2. Boot a guest
>>
>> - Sort method
>> 1.
>>   Confirm which the kvm_write_tsc_offset events are recorded except for
>> boot. Note that a vcpu thread writes TSC offset when boot as an initial
>> operation.
>>
>> 1-1.
>>   If not recorded, it means that the guest did not execute write_tsc.
>> So, we convert the guest TSC to the host TSC using TSC offset of boot.
>> => END
>>
>> 1-2.
>>   If recorded, it means that the guest executed write_tsc.
>> So, we use new kvm_write_tsc_offset event information.
>>
>> 2.
>> We convert the host TSC(Th) of the kvm_write_tsc_offset event to
>> the guest TSC(Tg) using previous_tsc_offset value:
>>      Tg = Th + previous_tsc_offset
>>
>> 3.
>> To search the point where the guest executed write_tsc, we find "n"
>> which satisfies the condition Tn < Tg < Tn+1 or Tn+1 < Tn < Tg from
>> older events of the guest.
>> The former condition means trace data of
>> the guest were recorded monotonically. On the other hand, the latter
>> condition means trace data of the guest moved backward.
>> 4.
>> We convert the guest TSC of trace data to the host TSC using
>> previous_tsc_offset value before "n" and using next_tsc_offset value
>> after "n+1".
>> => END
>>
>> - Note
>> We assumed one vcpu and no write_tsc or write_tsc only once for the
>> sake of ease. For other conditions, we will use similar method.
>>
>> Thanks,
>
> There is no certainty. Consider the following information available
>
> guest trace			host trace
> 				100: guest_tsc_write (tsc_offset=-100 => guest_tsc = 0)
> 				104: guest_tsc_write (tsc_offset=-104 => guest_tsc = 0)
> 				108: guest_tsc_write (tsc_offset=-108 => guest_tsc = 0)
> 1: eventA 			
> 2: eventB
> 3: eventC
> 1: eventD
> 2: eventE
> 3: eventF
>
> How can you tell which tsc_offset to use for eventD ? It could be either
> -104 or -108. The notion of "next_tsc_offset" is subject to such
> issue.
>
> I suppose its fine to restrict the interface as follows: the tool will
> accept one trace of events with monotonic timestamps and the user is
> responsible for correlating that to a host trace.

OK, I'll add the restriction, which trace data must have monotonic
timestamps to use this feature. I think guests seldom will execute
write_tsc, so in many cases, timestamps will be monotonically recorded
in trace data.

> That is, you can't feed distinct instances of guest kernel trace.

I'm not clear for "distinct instances". Is this about SMP or multiple
guests? Would you explain about this?

Thanks,

-- 
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/