[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] x86_emulate: Emulate RDTSCP instruction.



On 17/12/2009 05:56, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:

> Hi, Keir
> After adding the logic, it can solve the migration issue between
> rdtscp-capable machine and rdtsc-less machine, but it also introduces a
> security hole at the same time.  Imagine the case below:
> If boot a guest on a rdtsc-less machine and cpuid instruction tells the guest
> OS that processor doesn't support rdtscp instruction, but rdtscp can execute
> successfully on it instead of hitting a expected #UD exception. And guest can
> use this security hole to detect whether it is running in a virutal machine or
> not.  Thanks!

There's no doubt a guest could already detect this if it wanted, even from
user space. If this was seriously part of our threat model, we'd need to be
much more careful than we are. As it is we explicitly announce our presence
via CPUID in a way that cannot be turned off!

 -- Keir

> Xiantao
> 
> 
> Keir Fraser wrote:
>> Would have done if the original HVM TSC_AUX patch was up to it. I've
>> rewritten it about 1/4 the size and does more, as c/s 20646.
>> 
>>  -- Keir
>> 
>> On 16/12/2009 20:27, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
>> wrote: 
>> 
>>> Is this patch supposed to allow an application
>>> in an HVM domain to successfully execute an rdtscp
>>> instruction even on a processor that doesn't have
>>> hardware support for the instruction?
>>> 
>>> If so, I tried it and it doesn't seem to work.
>>> The app segfaults (same, I think, as it did before
>>> the patch).
>>> 
>>>> -----Original Message-----
>>>> From: Xen patchbot-unstable
>>>> [mailto:patchbot-unstable@xxxxxxxxxxxxxxxxxxx]
>>>> Sent: Wednesday, December 16, 2009 7:00 AM
>>>> To: xen-changelog@xxxxxxxxxxxxxxxxxxx
>>>> Subject: [Xen-changelog] [xen-unstable] x86_emulate: Emulate RDTSCP
>>>> instruction. 
>>>> 
>>>> 
>>>> # HG changeset patch
>>>> # User Keir Fraser <keir.fraser@xxxxxxxxxx>
>>>> # Date 1260967518 0
>>>> # Node ID cbcb3d564b2fb51574b8a1d06cd6e7780839c331
>>>> # Parent  b543acc1aaad743f20e8ee44ab048ca239350685
>>>> x86_emulate: Emulate RDTSCP instruction.
>>>> 
>>>> Signed-off-by: Keir Fraser <keir.fraser@xxxxxxxxxx> ---
>>>>  xen/arch/x86/x86_emulate/x86_emulate.c |   13 ++++++++++++-
>>>>  1 files changed, 12 insertions(+), 1 deletion(-)
>>>> 
>>>> diff -r b543acc1aaad -r cbcb3d564b2f
>>>> xen/arch/x86/x86_emulate/x86_emulate.c
>>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c Wed Dec 16 12:32:35
>>>> 2009 +0000 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c Wed Dec 16
>>>> 12:45:18 2009 +0000 @@ -292,6 +292,7 @@ struct operand {
>>>>  #define MSR_LSTAR        0xc0000082
>>>>  #define MSR_CSTAR        0xc0000083
>>>>  #define MSR_FMASK        0xc0000084
>>>> +#define MSR_TSC_AUX      0xc0000103
>>>> 
>>>>  /* Control register flags. */
>>>>  #define CR0_PE    (1<<0)
>>>> @@ -3503,6 +3504,16 @@ x86_emulate(
>>>>              break;
>>>>          }
>>>> 
>>>> +        if ( modrm == 0xf9 ) /* rdtscp */
>>>> +        {
>>>> +            uint64_t tsc_aux;
>>>> +            fail_if(ops->read_msr == NULL);
>>>> +            if ( (rc = ops->read_msr(MSR_TSC_AUX, &tsc_aux, ctxt))
>>>> != 0 ) +                goto done;
>>>> +            _regs.ecx = (uint32_t)tsc_aux;
>>>> +            goto rdtsc;
>>>> +        }
>>>> +
>>>>          switch ( modrm_reg & 7 )
>>>>          {
>>>>          case 0: /* sgdt */
>>>> @@ -3712,7 +3723,7 @@ x86_emulate(
>>>>          break;
>>>>      }
>>>> 
>>>> -    case 0x31: /* rdtsc */ {
>>>> +    case 0x31: rdtsc: /* rdtsc */ {
>>>>          unsigned long cr4;
>>>>          uint64_t val;
>>>>          if ( !mode_ring0() )
>>>> 
>>>> _______________________________________________
>>>> Xen-changelog mailing list
>>>> Xen-changelog@xxxxxxxxxxxxxxxxxxx
>>>> http://lists.xensource.com/xen-changelog
>>>> 
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.