linux-kernel - Re: [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to serialize

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: <20161202073435.GA14396@gmail.com>
Date:   Fri, 2 Dec 2016 08:34:35 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Andy Lutomirski <luto@...nel.org>, x86@...nel.org,
        One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Brian Gerst <brgerst@...il.com>,
        Matthew Whitehead <tedheadster@...il.com>,
        Henrique de Moraes Holschuh <hmh@....eng.br>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH 4/4] x86/asm: Change sync_core() to use MOV to CR2 to
 serialize

* Borislav Petkov <bp@...en8.de> wrote:

> On Wed, Nov 30, 2016 at 12:34:55PM -0800, Andy Lutomirski wrote:
> > Aside from being excessively slow, CPUID is problematic: Linux runs
> > on a handful of CPUs that don't have CPUID.  MOV to CR2 is always
> > available, so use it instead.
> > 
> > Signed-off-by: Andy Lutomirski <luto@...nel.org>
> > ---
> >  arch/x86/include/asm/processor.h | 31 ++++++++-----------------------
> >  1 file changed, 8 insertions(+), 23 deletions(-)
> 
> Looks nice.
> 
> I'm wondering if we should leave this one in tip for an additional cycle
> to have it tested on more hw. I know, it is architectural and so on but
> who knows what every implementation actually does...

I think -tip and "upstream of the day" mostly gets tested on relatively recent x86 
hardware - proven by the fact that these regressions are many months old.

The reason v4.9 got extra testing is the announced Long Term Support (LTS) aspect: 
more, older, weirder hardware is being tested because it's going to be a very 
popular base kernel.

So the best option would be to get these fixes into -tip, make sure it's sane all 
around and works on hardware that gets tested on bleeding edge kernels, then push 
it upstream sooner rather than later and also have Cc:stable tags on the obvious 
fixes, and handle any eventual fallout as it happens.

That's the best we can do I think.

Thanks,

	Ingo