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]

Message-ID: <20161216115254.GA18902@gmail.com>
Date:   Fri, 16 Dec 2016 12:52:54 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
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


* 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.

Thanks,

	Ingo