I just tested the 4.15 kernel and it is reporting that my old i486
(non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
Spectre V1, and Spectre V2.
I find this to be _unlikely_.
/sys/devices/system/cpu/vulnerabilities/* reports the following:
meltdown: "Vulnerable"
spectre_v1: "Vulnerable"
spectre_v2: "Vulnerable: Minimal generic ASM retpoline"
The output of dmesg includes:
"Spectre V2 mitigation: Vulnerable: Minimal generic ASM retpoline"
"Spectre V2 mitigation: Filling RSB on context switch"
Also, /proc/cpuinfo reports the following:
cpuid level: -1
flags: fpu retpoline rsb_ctxsw
bugs: cpu_meltdown spectre_v1 spectre_v2
I have the hardware to test on. Send me your patches.
- Matthew Whitehead
On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
> I just tested the 4.15 kernel and it is reporting that my old i486
> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
> Spectre V1, and Spectre V2.
>
> I find this to be _unlikely_.
This should be fixed in Linus' tree already by commit fec9434a1
("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
Meltdown").
We'll make sure it ends up in the stable tree too, if it hasn't
already.
On Sat, Feb 3, 2018 at 2:37 AM, David Woodhouse <[email protected]> wrote:
> On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
>> I just tested the 4.15 kernel and it is reporting that my old i486
>> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
>> Spectre V1, and Spectre V2.
>>
>> I find this to be _unlikely_.
>
> This should be fixed in Linus' tree already by commit fec9434a1
> ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
> Meltdown").
>
> We'll make sure it ends up in the stable tree too, if it hasn't
> already.
David
I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
Pull x86/pti updates from Thomas Gleixner: "Another set of melted
spectrum related changes"
(commit 6304672b7f0a5c010002e63a075160856dc4f88d).
Unfortunately, the symptoms I reported remain on at least the i486 and i686.
- Matthew
On Tue, Feb 06, 2018 at 01:33:30PM -0500, tedheadster wrote:
> On Sat, Feb 3, 2018 at 2:37 AM, David Woodhouse <[email protected]> wrote:
> > On Fri, 2018-02-02 at 23:52 -0500, tedheadster wrote:
> >> I just tested the 4.15 kernel and it is reporting that my old i486
> >> (non-cpuid capable) cpu is vulnerable to all three issues: Meltdown,
> >> Spectre V1, and Spectre V2.
> >>
> >> I find this to be _unlikely_.
> >
> > This should be fixed in Linus' tree already by commit fec9434a1
> > ("x86/pti: Do not enable PTI on CPUs which are not vulnerable to
> > Meltdown").
> >
> > We'll make sure it ends up in the stable tree too, if it hasn't
> > already.
>
> David
> I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
>
> Pull x86/pti updates from Thomas Gleixner: "Another set of melted
> spectrum related changes"
> (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
>
> Unfortunately, the symptoms I reported remain on at least the i486 and i686.
Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
was a lot of spectrum patches merged just this week that were not in
4.15.1.
thanks,
greg k-h
On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
> .
> >
> > David
> > I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
> >
> > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
> > spectrum related changes"
> > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
> >
> > Unfortunately, the symptoms I reported remain on at least the i486 and i686.
>
> Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
> was a lot of spectrum patches merged just this week that were not in
> 4.15.1.
No, for the 486 it *should* have worked. The interesting commit
is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
vulnerable to Meltdown") which is indeed pulled in with the merge
commit that Matthew mentions.
Matthew, can you show the content of /proc/cpuinfo please? And perhaps
add a printk or two in early_identify_cpu() to work out what's going
on?
Your CPU *should* hit the x86_match_cpu(cpu_no_speculation) case and
not set any of the three bugs, AFAICT.
On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote:
>
>
> On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
> > .
> > >?
> > > David
> > >?? I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
> > >?
> > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
> > > spectrum related changes"
> > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
> > >?
> > > Unfortunately, the symptoms I reported remain on at least the i486 and i686.
> >
> > Can you try 4.15.2-rc1?? Or how about Linus's kernel tree now?? There
> > was a lot of spectrum patches merged just this week that were not in
> > 4.15.1.
>
> No, for the 486 it *should* have worked. The interesting commit
> is?fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
> vulnerable to Meltdown") which is indeed pulled in with the merge
> commit that Matthew mentions.
>
I disagree.
$ git describe
v4.15.1-61-g7ab5513e4cbc
$ git log --oneline v4.15.1.. | grep Melt
3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
Guenter
On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse <[email protected]> wrote:
> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>> On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote:
>> >
>> >
>> >
>> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
>> > >
>> > > .
>> > > >
>> > > >
>> > > > David
>> > > > I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
>> > > >
>> > > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
>> > > > spectrum related changes"
>> > > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
>> > > >
>> > > > Unfortunately, the symptoms I reported remain on at least the i486 and i686.
>> > > Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
>> > > was a lot of spectrum patches merged just this week that were not in
>> > > 4.15.1.
>> > No, for the 486 it *should* have worked. The interesting commit
>> > is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
>> > vulnerable to Meltdown") which is indeed pulled in with the merge
>> > commit that Matthew mentions.
>> >
>> I disagree.
>>
>> $ git describe
>> v4.15.1-61-g7ab5513e4cbc
>> $ git log --oneline v4.15.1.. | grep Melt
>> 3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
>
> Ah right, for 4.15.1 perhaps yes. I was looking at Matthew's 'commit
> 6304672b7f0a5c010002e63a075160856dc4f88d' which isn't in 4.15.1 at all;
> that's the commit in Linus' tree where he pulled in the fix. So *that*
> one should have had it.
I think Guenter is correct and I mixed up my linux versus linux-stable
git repository directories. I am recompiling now Linus' tree and will
report back my results.
Apologies for the incorrect information.
- Matthew
On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
> On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote:
> >
> >
> >
> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
> > >
> > > .
> > > >
> > > >
> > > > David
> > > > I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
> > > >
> > > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
> > > > spectrum related changes"
> > > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
> > > >
> > > > Unfortunately, the symptoms I reported remain on at least the i486 and i686.
> > > Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
> > > was a lot of spectrum patches merged just this week that were not in
> > > 4.15.1.
> > No, for the 486 it *should* have worked. The interesting commit
> > is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
> > vulnerable to Meltdown") which is indeed pulled in with the merge
> > commit that Matthew mentions.
> >
> I disagree.
>
> $ git describe
> v4.15.1-61-g7ab5513e4cbc
> $ git log --oneline v4.15.1.. | grep Melt
> 3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
Ah right, for 4.15.1 perhaps yes. I was looking at Matthew's 'commit
6304672b7f0a5c010002e63a075160856dc4f88d' which isn't in 4.15.1 at all;
that's the commit in Linus' tree where he pulled in the fix. So *that*
one should have had it.
On Tue, Feb 6, 2018 at 2:24 PM, tedheadster <[email protected]> wrote:
> On Tue, Feb 6, 2018 at 2:17 PM, David Woodhouse <[email protected]> wrote:
>> On Tue, 2018-02-06 at 11:13 -0800, Guenter Roeck wrote:
>>> On Tue, Feb 06, 2018 at 07:10:27PM +0000, David Woodhouse wrote:
>>> >
>>> >
>>> >
>>> > On Tue, 2018-02-06 at 11:02 -0800, Greg Kroah-Hartman wrote:
>>> > >
>>> > > .
>>> > > >
>>> > > >
>>> > > > David
>>> > > > I believe I got the patch(es) you mention in in the stable 4.15.1 kernel:
>>> > > >
>>> > > > Pull x86/pti updates from Thomas Gleixner: "Another set of melted
>>> > > > spectrum related changes"
>>> > > > (commit 6304672b7f0a5c010002e63a075160856dc4f88d).
>>> > > >
>>> > > > Unfortunately, the symptoms I reported remain on at least the i486 and i686.
>>> > > Can you try 4.15.2-rc1? Or how about Linus's kernel tree now? There
>>> > > was a lot of spectrum patches merged just this week that were not in
>>> > > 4.15.1.
>>> > No, for the 486 it *should* have worked. The interesting commit
>>> > is fec9434a12 ("x86/pti: Do not enable PTI on CPUs which are not
>>> > vulnerable to Meltdown") which is indeed pulled in with the merge
>>> > commit that Matthew mentions.
>>> >
>>> I disagree.
>>>
>>> $ git describe
>>> v4.15.1-61-g7ab5513e4cbc
>>> $ git log --oneline v4.15.1.. | grep Melt
>>> 3472b3689bab x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
>>
>> Ah right, for 4.15.1 perhaps yes. I was looking at Matthew's 'commit
>> 6304672b7f0a5c010002e63a075160856dc4f88d' which isn't in 4.15.1 at all;
>> that's the commit in Linus' tree where he pulled in the fix. So *that*
>> one should have had it.
>
Okay, I did a 'git pull' from Linus' tree and rebuilt. I _believe_ I
have the correct patches from this information:
localhost /usr/src/linux # git log | grep "Do not enable PTI on CPUs
which are not vulnerable to Meltdown"
Fixes: fec9434a12f3 ("x86/pti: Do not enable PTI on CPUs which are
not vulnerable to Meltdown")
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
x86/pti: Do not enable PTI on CPUs which are not vulnerable to Meltdown
localhost /usr/src/linux # git log | grep -A8
6304672b7f0a5c010002e63a075160856dc4f88d
commit 6304672b7f0a5c010002e63a075160856dc4f88d
Merge: 942633523cde 64e16720ea08
Author: Linus Torvalds <[email protected]>
Date: Mon Jan 29 19:08:02 2018 -0800
Merge branch 'x86-pti-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86/pti updates from Thomas Gleixner:
"Another set of melted spectrum related changes:
If that is correct (and I might be wrong), then I am up to date and I
am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
bugs : cpu_meltdown spectre_v1 spectre_v2
- Matthew
On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
>
> If that is correct (and I might be wrong), then I am up to date and I
> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
>
> bugs : cpu_meltdown spectre_v1 spectre_v2
That's expected for now. The CPUs we exempt are as follows:
static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
{ X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
{ X86_VENDOR_CENTAUR, 5 },
{ X86_VENDOR_INTEL, 5 },
{ X86_VENDOR_NSC, 5 },
{ X86_VENDOR_ANY, 4 },
{}
};
Alan is going to improve that list, but your Pentium 4 isn't on it yet.
The bugs went away on the 486 though, right?
> If that is correct (and I might be wrong), then I am up to date and I
> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
>
> bugs : cpu_meltdown spectre_v1 spectre_v2
>
> - Matthew
That's an interesting museum piece. It's a Northwood core so I believe
the reporting is correct.
Alan
On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse <[email protected]> wrote:
> On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
>>
>> If that is correct (and I might be wrong), then I am up to date and I
>> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
>>
>> bugs : cpu_meltdown spectre_v1 spectre_v2
>
> That's expected for now. The CPUs we exempt are as follows:
>
> static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL, X86_FEATURE_ANY },
> { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY },
> { X86_VENDOR_CENTAUR, 5 },
> { X86_VENDOR_INTEL, 5 },
> { X86_VENDOR_NSC, 5 },
> { X86_VENDOR_ANY, 4 },
> {}
> };
>
> Alan is going to improve that list, but your Pentium 4 isn't on it yet.
>
> The bugs went away on the 486 though, right?
Okay, recompiled for the i486 and it reports no bugs.
As for the i686, it is really a "Mobile Pentium 4 HT" Prescott series
(https://ark.intel.com/products/27368/Mobile-Intel-Pentium-4-Processor-532-supporting-HT-Technology-1M-Cache-3_06-GHz-533-MHz-FSB).
Does that make it a 'speculative execution' processor?
Thank you for the help and I'll test more of the museum pieces.
- Matthew
On Tuesday 06 February 2018, tedheadster wrote:
> On Tue, Feb 6, 2018 at 3:54 PM, David Woodhouse <[email protected]> wrote:
> > On Tue, 2018-02-06 at 15:45 -0500, tedheadster wrote:
> >> If that is correct (and I might be wrong), then I am up to date and I
> >> am still getting the following in /proc/cpuinfo on my Pentium 4M i686:
> >>
> >> bugs : cpu_meltdown spectre_v1 spectre_v2
> >
> > That's expected for now. The CPUs we exempt are as follows:
> >
> > static const __initdata struct x86_cpu_id cpu_no_speculation[] = {
> > { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CEDARVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_CLOVERVIEW,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_LINCROFT,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_PENWELL,
> > X86_FEATURE_ANY }, { X86_VENDOR_INTEL, 6,
> > INTEL_FAM6_ATOM_PINEVIEW, X86_FEATURE_ANY }, { X86_VENDOR_CENTAUR, 5
> > },
> > { X86_VENDOR_INTEL, 5 },
> > { X86_VENDOR_NSC, 5 },
> > { X86_VENDOR_ANY, 4 },
> > {}
> > };
> >
> > Alan is going to improve that list, but your Pentium 4 isn't on it yet.
> >
> > The bugs went away on the 486 though, right?
>
> Okay, recompiled for the i486 and it reports no bugs.
>
> As for the i686, it is really a "Mobile Pentium 4 HT" Prescott series
> (https://ark.intel.com/products/27368/Mobile-Intel-Pentium-4-Processor-532-
>supporting-HT-Technology-1M-Cache-3_06-GHz-533-MHz-FSB). Does that make it a
> 'speculative execution' processor?
>
> Thank you for the help and I'll test more of the museum pieces.
>
> - Matthew
What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
MMX). I've tried a spectre test before and it wasn't reading anything useful.
Don't know about meltdown. Is there a complete test program? (The web is so
full of crap that even google can't find anything useful.)
--
Ondrej Zary
> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
> MMX). I've tried a spectre test before and it wasn't reading anything useful.
> Don't know about meltdown. Is there a complete test program? (The web is so
> full of crap that even google can't find anything useful.)
Pentium MMX does not speculate. Pentium II does.
For meltdown there are some reasonably easy tests to run to look for a
positive. Proving a negative is much much harder however and as far as I
am aware nobody has done a full evaluation of processors that old.
For x86 speculation came in (as far as I can tell) in
AMD Am5x86
Cyrix 5x86, but branch predictors are disabled by default according to
the docs
Cyrix 6x86, branch prediction on by default
Pentium Pro
There are later processors that don't have speculation: Quark series, Nat
Semi/Cyrix Geode, earliest AMD geode (I think), some Intel Atom
processors.
The more obscure ones - the Transmeta apparently may, the IDT Winchip
documentation strongly implies it doesn't, the Vortex86 (aka
SiS55X/Rise mP6) says it doesn't and things like the NexGen I have no
idea about.
The problem is that it's very hard to definitively answer questions on
these processors and vulnerabilities like they are obsolete, almost
nobody uses them for anything but retro stuff and the return on the effort
of figuring out defiitive answers is close to nil.
Alan
On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox <[email protected]> wrote:
>> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
>> MMX). I've tried a spectre test before and it wasn't reading anything useful.
>> Don't know about meltdown. Is there a complete test program? (The web is so
>> full of crap that even google can't find anything useful.)
>
> For x86 speculation came in (as far as I can tell) in
>
> AMD Am5x86
> Cyrix 5x86, but branch predictors are disabled by default according to
> the docs
> Cyrix 6x86, branch prediction on by default
> Pentium Pro
>
> There are later processors that don't have speculation: Quark series, Nat
> Semi/Cyrix Geode, earliest AMD geode (I think), some Intel Atom
> processors.
Wasn't Am5x86 just a 486 clone? AFAICT, speculation only came with the
K6 (Am6x86 aka NexGen Nx6x86)
All the Geode are apparently derived from Cyrix 5x86 (I always thought
it was a 6x86, but the internet disagrees). For Geode GX, a
specification update at [1] mentions a special procedure for enabling
branch prediction, Geode LX apparently gets this right and always
has branch prediction.
> The more obscure ones - the Transmeta apparently may, the IDT Winchip
> documentation strongly implies it doesn't
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.
Arnd
[1] http://support.amd.com/TechDocs/31533E_gx_2.1_specupdate.pdf
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
On Thu, Feb 8, 2018 at 12:02 PM, David Laight <[email protected]> wrote:
> 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
You might think this absolutely crazy, but I would be willing to test
such systems if I can get my hands on the needed hardware that I lack.
I am already doing sanity testing on Intel
i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
clone cpus (Cyrix, etc).
While few people are using the 32bit kernel, I don't think we want to
kill it completely just yet.
- Matthew
On Thu, Feb 8, 2018 at 12:02 PM, David Laight <[email protected]> wrote:
> 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
You might think this absolutely crazy, but I would be willing to test
such systems if I can get my hands on the needed hardware that I lack.
I am already doing sanity testing on Intel
i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
clone cpus (Cyrix, etc).
While few people are using the 32bit kernel, I don't think we want to
kill it completely just yet.
- Matthew
> > 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.
But they also have more instructions that take a lot of clocks and are
easier to stall - eg by doing things like opening and mmapping
a framebuffer and then doing a floating point double store to it
misaligned.
Meltdown we can at least reasonably test but spectre is hard.
Alan
On Thu, 8 Feb 2018 16:22:40 +0100
Arnd Bergmann <[email protected]> wrote:
> On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox <[email protected]> wrote:
> >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
> >> MMX). I've tried a spectre test before and it wasn't reading anything useful.
> >> Don't know about meltdown. Is there a complete test program? (The web is so
> >> full of crap that even google can't find anything useful.)
> >
> > For x86 speculation came in (as far as I can tell) in
> >
> > AMD Am5x86
> > Cyrix 5x86, but branch predictors are disabled by default according to
> > the docs
> > Cyrix 6x86, branch prediction on by default
> > Pentium Pro
> >
> > There are later processors that don't have speculation: Quark series, Nat
> > Semi/Cyrix Geode, earliest AMD geode (I think), some Intel Atom
> > processors.
>
> Wasn't Am5x86 just a 486 clone? AFAICT, speculation only came with the
> K6 (Am6x86 aka NexGen Nx6x86)
The AMD 486 was a 486, just like UMC. The Am5x86 was a sort of super 486.
But you are correct I'm muddling that with the K5 - which does speculate
or at least some of them do. The K5 branch predictor is software
controllable via the HWCR MSR but who has one today to test or cares 8)
> All the Geode are apparently derived from Cyrix 5x86 (I always thought
Not quite all. The older ones are Cyrix 5x86 related which indeed means
they don't have branch prediction on by default until the LX. Just to
confuse the AMD Geode NX is basically an Athlon mobile.
Alan
On Thu, Feb 8, 2018 at 6:27 PM, tedheadster <[email protected]> wrote:
> On Thu, Feb 8, 2018 at 12:02 PM, David Laight <[email protected]> wrote:
>> 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.
>
> You might think this absolutely crazy, but I would be willing to test
> such systems if I can get my hands on the needed hardware that I lack.
> I am already doing sanity testing on Intel
> i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
> clone cpus (Cyrix, etc).
VIA machines are available for pocket change in many countries,
this one is what I'd get if I wanted to test over here:
http://www.ebay.de/itm/IGEL-UD2-D200-VIA-C7-M-500MHz-1GB-1GB-Flash-Memory-Thin-Client-ohne-Netzteil/301860030372
Similarly, the 6x86 (Cyrix, ST or IBM branded are identical) is really
easy to get by itself and should fit in many Socket 7 mainboards, which
you apparently already have.
Arnd
On Thu, Feb 8, 2018 at 10:16 PM, Alan Cox <[email protected]> wrote:
> On Thu, 8 Feb 2018 16:22:40 +0100
> Arnd Bergmann <[email protected]> wrote:
>
>> On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox <[email protected]> wrote:
>> >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
>> >> MMX). I've tried a spectre test before and it wasn't reading anything useful.
>> >> Don't know about meltdown. Is there a complete test program? (The web is so
>> >> full of crap that even google can't find anything useful.)
>> >
>> > For x86 speculation came in (as far as I can tell) in
>> >
>> > AMD Am5x86
>> > Cyrix 5x86, but branch predictors are disabled by default according to
>> > the docs
>> > Cyrix 6x86, branch prediction on by default
>> > Pentium Pro
>> >
>> > There are later processors that don't have speculation: Quark series, Nat
>> > Semi/Cyrix Geode, earliest AMD geode (I think), some Intel Atom
>> > processors.
>>
>> Wasn't Am5x86 just a 486 clone? AFAICT, speculation only came with the
>> K6 (Am6x86 aka NexGen Nx6x86)
>
> The AMD 486 was a 486, just like UMC. The Am5x86 was a sort of super 486.
> But you are correct I'm muddling that with the K5 - which does speculate
> or at least some of them do. The K5 branch predictor is software
> controllable via the HWCR MSR but who has one today to test or cares 8)
Right, I completely forgot about the K5.
>> All the Geode are apparently derived from Cyrix 5x86 (I always thought
>
> Not quite all. The older ones are Cyrix 5x86 related which indeed means
> they don't have branch prediction on by default until the LX. Just to
> confuse the AMD Geode NX is basically an Athlon mobile.
This one I knew, I was just not using precise enough language.
Arnd
On Thursday 08 February 2018, tedheadster wrote:
> On Thu, Feb 8, 2018 at 12:02 PM, David Laight <[email protected]>
wrote:
> > 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
>
> You might think this absolutely crazy, but I would be willing to test
> such systems if I can get my hands on the needed hardware that I lack.
> I am already doing sanity testing on Intel
> i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
> clone cpus (Cyrix, etc).
>
> While few people are using the 32bit kernel, I don't think we want to
> kill it completely just yet.
>
> - Matthew
I have a working Cyrix MII (was actively using it last year, now upgraded to a
P3-based Celeron). Some AMD CPUs too - K6(maybe -2 or -3?), not sure about K5
and also a Rise mP6. But never got a WinChip.
So the question is: what to test?
BTW. Kernel was not able to identify mP6 CPU 6 years ago, patches were
ignored.
--
Ondrej Zary
Hi!
> > You might think this absolutely crazy, but I would be willing to test
> > such systems if I can get my hands on the needed hardware that I lack.
> > I am already doing sanity testing on Intel
> > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
> > clone cpus (Cyrix, etc).
> >
> > While few people are using the 32bit kernel, I don't think we want to
> > kill it completely just yet.
>
> I have a working Cyrix MII (was actively using it last year, now upgraded to a
> P3-based Celeron). Some AMD CPUs too - K6(maybe -2 or -3?), not sure about K5
> and also a Rise mP6. But never got a WinChip.
I'm using Core Duo daily (backup machine, web browsing), and use
Pentium M as an ssh client say once in month.
> So the question is: what to test?
Self-compiling kernel is traditional stability test.
I do have two Geodes I believe, but the hardware is quite nasty to
use. (One has some kind of forth-based BIOS -- forgot the name).
> BTW. Kernel was not able to identify mP6 CPU 6 years ago, patches were
> ignored.
You may want to re-send :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu 2018-02-08 20:52:40, Alan Cox wrote:
> > > 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.
>
> But they also have more instructions that take a lot of clocks and are
> easier to stall - eg by doing things like opening and mmapping
> a framebuffer and then doing a floating point double store to it
> misaligned.
>
> Meltdown we can at least reasonably test but spectre is hard.
Do you have pointer for simple meltdown test?
I've got https://github.com/IAIK/meltdown.git but could not get it to
work even on machines that should be vulnerable.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 13 Feb 2018 22:04:48 +0100
Pavel Machek <[email protected]> wrote:
> On Thu 2018-02-08 20:52:40, Alan Cox wrote:
> > > > 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.
> >
> > But they also have more instructions that take a lot of clocks and are
> > easier to stall - eg by doing things like opening and mmapping
> > a framebuffer and then doing a floating point double store to it
> > misaligned.
> >
> > Meltdown we can at least reasonably test but spectre is hard.
>
> Do you have pointer for simple meltdown test?
It's CPU dependent but for the older processors you probably want one of
the small ones as you've got much less cache and speculation to play with.
And then you also need the test data to be in L1 D cache
Alan
Hi!
> > > You might think this absolutely crazy, but I would be willing to test
> > > such systems if I can get my hands on the needed hardware that I lack.
> > > I am already doing sanity testing on Intel
> > > i486/i586/i586-MMX/i686-PentiumPro systems, I just don't have the
> > > clone cpus (Cyrix, etc).
> > >
> > > While few people are using the 32bit kernel, I don't think we want to
> > > kill it completely just yet.
> >
> > I have a working Cyrix MII (was actively using it last year, now upgraded to a
> > P3-based Celeron). Some AMD CPUs too - K6(maybe -2 or -3?), not sure about K5
> > and also a Rise mP6. But never got a WinChip.
>
> I'm using Core Duo daily (backup machine, web browsing), and use
> Pentium M as an ssh client say once in month.
BTW... I'd really like to have a database of machine, kernel version,
cpuinfo, config... So that questions like "what is the latest kernel
that is known to be running on this hardware" and "what config should
I start from".
For example, I have nokia N810 here. It was supported by Linux at some
point, but then we moved to dts, and stuff changed, and I can no
longer figure how to boot it.
I guess "what was last kernel that worked on Cyrix MII" is also
relevant question.
Is there such database? If not, would people be interested in
contributing if I create one?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> BTW... I'd really like to have a database of machine, kernel version,
> cpuinfo, config... So that questions like "what is the latest kernel
> that is known to be running on this hardware" and "what config should
> I start from".
>
> For example, I have nokia N810 here. It was supported by Linux at some
> point, but then we moved to dts, and stuff changed, and I can no
> longer figure how to boot it.
>
> I guess "what was last kernel that worked on Cyrix MII" is also
> relevant question.
>
> Is there such database? If not, would people be interested in
> contributing if I create one?
>
I am interested and will help. I have i486/i586/Pentium Pro/Pentium
II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet
have Pentium III systems.
I think an associated goal would be to fix those broken versions.
I think this is a great project for college students to get experience
with. Who else is interested?
- Matthew Whitehead
Hi!
> > BTW... I'd really like to have a database of machine, kernel version,
> > cpuinfo, config... So that questions like "what is the latest kernel
> > that is known to be running on this hardware" and "what config should
> > I start from".
> >
> > For example, I have nokia N810 here. It was supported by Linux at some
> > point, but then we moved to dts, and stuff changed, and I can no
> > longer figure how to boot it.
> >
> > I guess "what was last kernel that worked on Cyrix MII" is also
> > relevant question.
> >
> > Is there such database? If not, would people be interested in
> > contributing if I create one?
> >
>
> I am interested and will help. I have i486/i586/Pentium Pro/Pentium
> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet
> have Pentium III systems.
>
> I think an associated goal would be to fix those broken versions.
>
> I think this is a great project for college students to get experience
> with. Who else is interested?
Ok, I started something:
https://github.com/pavelmachek/missy
I try to test -rc1 and final versions on thinkpads X60 and X220. (I'd
like to do testing of even -next from time to time.) I do have T40p
and test maybe every other version on that one. I test Nokia N900
quite often (including next), and plan to test N9/N950 too.
Of course, more "exotic" hardware would be welcome. I did have linux
on sun4/330, unfortunately I don't think I have access to that any
more.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Feb 17, 2018 at 4:16 PM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> > BTW... I'd really like to have a database of machine, kernel version,
>> > cpuinfo, config... So that questions like "what is the latest kernel
>> > that is known to be running on this hardware" and "what config should
>> > I start from".
>> >
>> > For example, I have nokia N810 here. It was supported by Linux at some
>> > point, but then we moved to dts, and stuff changed, and I can no
>> > longer figure how to boot it.
>> >
>> > I guess "what was last kernel that worked on Cyrix MII" is also
>> > relevant question.
>> >
>> > Is there such database? If not, would people be interested in
>> > contributing if I create one?
>> >
>>
>> I am interested and will help. I have i486/i586/Pentium Pro/Pentium
>> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet
>> have Pentium III systems.
>>
>> I think an associated goal would be to fix those broken versions.
>>
>> I think this is a great project for college students to get experience
>> with. Who else is interested?
>
> Ok, I started something:
>
> https://github.com/pavelmachek/missy
>
This is a good start. Could we start to create a hierarchy of major
architectures next? I propose the following:
i486->Intel->i486
i486->Cyrix->Cx486
i486->AMD->Am486
i486->UMC->Green CPU
i586->Intel->Pentium Classic
i586->Intel->Pentium MMX
i586->Intel->Atom
i586->AMD->K5
i586->AMD->K6
i586->AMD->K6 II
i586->AMD->K6 III
i586->Cyrix->5x86
i586->Cyrix->6x86
i586->Cyrix->6x86MX
i586->Cyrix->Cyrix III
i686->Intel->Pentium Pro
i686->Intel->Pentium II
i686->Intel->Pentium III
i686->Intel->Pentium 4
i686->Intel->Pentium M
i686->Intel->Core 2
i686->AMD->K7
i686->AMD->K8
You would put the computer you tested it on inside one of these directories.
This will need to be edited if you choose to use it. I left out items
I know little about, such as Geode GX1, Geode LX, VIA C3-2, VIA C7,
Transmeta Crusoe and Efficeon, Winchip-2, Winchip-C6, and certainly
others.
- Matthew
Hi!
> >> > BTW... I'd really like to have a database of machine, kernel version,
> >> > cpuinfo, config... So that questions like "what is the latest kernel
> >> > that is known to be running on this hardware" and "what config should
> >> > I start from".
> >> >
> >> > For example, I have nokia N810 here. It was supported by Linux at some
> >> > point, but then we moved to dts, and stuff changed, and I can no
> >> > longer figure how to boot it.
> >> >
> >> > I guess "what was last kernel that worked on Cyrix MII" is also
> >> > relevant question.
> >> >
> >> > Is there such database? If not, would people be interested in
> >> > contributing if I create one?
> >> >
> >>
> >> I am interested and will help. I have i486/i586/Pentium Pro/Pentium
> >> II/Pentium II Xeon/Pentium 4 systems to test on. Oddly, I don't yet
> >> have Pentium III systems.
> >>
> >> I think an associated goal would be to fix those broken versions.
> >>
> >> I think this is a great project for college students to get experience
> >> with. Who else is interested?
> >
> > Ok, I started something:
> >
> > https://github.com/pavelmachek/missy
> >
> This is a good start. Could we start to create a hierarchy of major
> architectures next? I propose the following:
For desktop PCs, I guess grouping by CPU type makes sense. But I guess
I'd prefer grouping CPUs by manufacturer, not by CPU "family".
So I'd propose
pc/intel/i486
pc/cyrix/cx486
pc/amd/am486
...
> You would put the computer you tested it on inside one of these directories.
>
> This will need to be edited if you choose to use it. I left out items
> I know little about, such as Geode GX1, Geode LX, VIA C3-2, VIA C7,
> Transmeta Crusoe and Efficeon, Winchip-2, Winchip-C6, and certainly
> others.
Advantage is, that even if you know little about the chip, you know
who manufactured it and how it is called :-).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html