linux-kernel - RE: [BUG] x86 : i486 reporting to be vulnerable to Meltdown/Spectre_V1/Spectre

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:   Thu, 8 Feb 2018 17:02:14 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Arnd Bergmann' <arnd@...db.de>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>
CC:     Ondrej Zary <linux@...nbow-software.org>,
        "whiteheadm@....org" <whiteheadm@....org>,
        David Woodhouse <dwmw2@...radead.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Hugh Dickins" <hughd@...gle.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "Jiri Kosina" <jikos@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Kees Cook <keescook@...omium.org>,
        Jamie Iles <jamie@...ieiles.com>,
        Eduardo Valentin <eduval@...zon.com>,
        Laura Abbott <labbott@...hat.com>,
        Rik van Riel <riel@...riel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: [BUG] x86 : i486 reporting to be vulnerable to
 Meltdown/Spectre_V1/Spectre_V2

From: Arnd Bergmann
> Sent: 08 February 2018 15:23
...
> The Winchip is what eventually turned into the VIA Nano, which does
> have speculative execution, but I don't think the earlier C3 and C7 did,
> they are much closer to the original Winchip design.

We had terrible trouble getting (IIRC) the C7 to execute functions
that were called in 16bit mode and returned in 32bit mode and v.v.
(for boot code bios calls).
The problems seemed to imply that it was caching return addresses
and the translation (to uops) of the instructions that followed.
So it would effectively decode the first few bytes in the wrong mode.
So there might be scope for one of these attacks.

OTOH these devices were so slow that I doubt any are used for anything
serious - and certainly won't get a kernel update even if they are.

Also worth nothing that the difference between the cpu and memory
speeds is much lower - so far fewer instructions could be speculatively
executed while waiting a cache miss.

Tempting to disable everything.

	David