linux-kernel - Re: [patch 2/2] x86/tsc: Force TSC_ADJUST register to value >= zero

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, 16 Dec 2016 12:53:24 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ingo Molnar <mingo@...nel.org>
cc:     LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Bruce Schlobohm <bruce.schlobohm@...el.com>,
        Roland Scheidegger <rscheidegger_lists@...peed.ch>,
        Kevin Stanton <kevin.b.stanton@...el.com>,
        Allen Hung <allen_hung@...l.com>, stable@...r.kernel.org
Subject: Re: [patch 2/2] x86/tsc: Force TSC_ADJUST register to value >=
 zero

On Fri, 16 Dec 2016, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@...utronix.de> wrote:
> 
> > We have two options:
> > 
> > 1) Disable TSC deadline timer by default and force users with sane machines
> >    to enable it on the kernel command line.
> > 
> >    Upside:   Very small patch
> >    
> >    Downside: Degrades existing setups on sane machines, keeps TSC unusable
> >       	     on affected machines. We have no idea what other hidden side
> >       	     effects the TSC_ADJUST tinkering has. If there are any, they
> >       	     ain't be nice ones.
> > 
> > 2) Push the whole TSC_ADJUST sanitizing machinery into stable
> > 
> >    Upside:   Does not affect sane machines and gives a benefit to users of
> >    	     affected machines
> > 
> >    Downside: Rather large patch, but not that risky either. Needs a few
> > 	     eyes and good test coverage though
> > 
> > Thoughts?
> 
> I'd go for #2, because #1 is essentially turning it off for almost everyone.
> 
> We can still do #1 and push it back to -stable as well if #2 fails.
> 
> But I'd suggest we delay the stable backporting until it's been upstream a bit.

I agree. None of these patches is tagged stable. I just wanted to mention
it so it can be discussed before distros/stable users are swamped with
failure reports.

Thanks,

	tglx