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] [day] [month] [year] [list]
Message-ID: <20170130155839.t6ku6kbqyegry7pm@pd.tnic>
Date:   Mon, 30 Jan 2017 16:58:39 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Henning Schild <henning.schild@...mens.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Yinghai Lu <yinghai@...nel.org>
Subject: Re: [3/8] x86/tsc: Store and check TSC ADJUST MSR

On Mon, Jan 30, 2017 at 02:04:46PM +0100, Thomas Gleixner wrote:
> > The AMD-Manual from 12/16 does not mention that MSR. I do not have
> > access to an AMD machine. But i can only assume that bigger machines
> > also suffer from async TSCs and basically all fall back to HPET.
> 
> Borislav?

So far, all AMD machines starting from Barcelona (F10h) onwards should
have a stable TSC. If you've seen some discrepancies, make sure to
let us know. The bigger machines I have access to are all ok wrt
synchronized TSCs but I won't be surprised if someone proves me wrong.

Of course, if dumb firmware decides to fiddle with the TSC, then dumb
firmware should be fixed.

Wrt TSC adjust MSR, it should be probably best to take this up with AMD
engineering.

HTH.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ