linux-kernel - Re: [PATCH] ensure guest's kvmclock never goes backwards when TSC jumps backward

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]

Message-ID: <53C6517D.9090600@redhat.com>
Date:	Wed, 16 Jul 2014 12:18:37 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Igor Mammedov <imammedo@...hat.com>, linux-kernel@...r.kernel.org
CC:	kvm@...r.kernel.org, x86@...nel.org, mtosatti@...hat.com
Subject: Re: [PATCH] ensure guest's kvmclock never goes backwards when TSC
 jumps backward

Il 16/07/2014 11:52, Igor Mammedov ha scritto:
> There are buggy hosts in the wild that advertise invariant
> TSC and as result host uses TSC as clocksource, but TSC on
> such host sometimes sporadically jumps backwards.
>
> This causes kvmclock to go backwards if host advertises
> PVCLOCK_TSC_STABLE_BIT, which turns off aggregated clock
> accumulator and returns:
>   pvclock_vcpu_time_info.system_timestamp + offset
> where 'offset' is calculated using TSC.
> Since TSC is not virtualized in KVM, it makes guest see
> TSC jumped backwards and leads to kvmclock going backwards
> as well.
>
> This is defensive patch that keeps per CPU last clock value
> and ensures that clock will never go backwards even with
> using PVCLOCK_TSC_STABLE_BIT enabled path.

I'm not sure that a per-CPU value is enough; your patch can make the 
problem much less frequent of course, but I'm not sure neither detection 
nor correction are 100% reliable.  Your addition is basically a faster 
but less reliable version of the last_value logic.

If may be okay to have detection that is faster but not 100% reliable. 
However, once you find that the host is buggy I think the correct thing 
to do is to write last_value and kill PVCLOCK_TSC_STABLE_BIT from 
valid_flags.

Did you check that the affected host has the latest microcode? 
Alternatively, could we simply blacklist some CPU steppings?  I'm not 
sure who we could ask at AMD :( but perhaps there is an erratum.

Paolo
--
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/