Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #51696 > unrolled thread

Linux 4.20 is Running Slower Than 4.19 On Intel CPUs

Back to article view | Back to alt.os.linux

Contents

  Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <noreply@mixnym.net> - 2018-11-16 20:21 -0600
    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-17 11:10 +0100
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Carlos E.R." <robin_listas@es.invalid> - 2018-11-17 11:26 +0100
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-17 11:53 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Carlos E.R." <robin_listas@es.invalid> - 2018-11-18 21:06 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Paul <nospam@needed.invalid> - 2018-11-18 15:46 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Bud Frede <frede@mouse-potato.com> - 2018-11-24 09:07 -0500
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-18 22:27 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-19 08:27 +0000
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-19 18:33 +0000
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-19 21:02 +0100
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-20 04:46 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "J.O. Aho" <user@example.net> - 2018-11-20 06:59 +0100
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs not@telling.you.invalid (Computer Nerd Kev) - 2018-11-19 21:58 +0000
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-11-19 17:27 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2018-11-19 17:37 -0500
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-20 10:10 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-20 15:51 -0500
                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs not@telling.you.invalid (Computer Nerd Kev) - 2018-11-20 21:31 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-20 23:14 +0000
                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-21 06:50 +0000
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Paul <nospam@needed.invalid> - 2018-11-21 04:24 -0500
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-21 10:56 +0000
                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-21 12:22 +0000
                      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Richard Kettlewell <invalid@invalid.invalid> - 2018-11-21 13:24 +0000
                        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-21 22:08 +0000
                          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs William Unruh <unruh@invalid.ca> - 2018-11-21 23:53 +0000
                            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-24 11:46 +0000
                              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs William Unruh <unruh@invalid.ca> - 2018-11-24 13:53 +0000
                                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-24 18:39 +0000
                                Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-24 15:47 -0500
                                  Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-11-25 07:51 +0000
                                    Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Andreas Kohlbach <ank@spamfence.net> - 2018-11-25 16:08 -0500
                              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Rich <rich@example.invalid> - 2018-11-24 15:24 +0000
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Soviet_Mario <SovietMario@CCCP.MIR> - 2018-11-30 11:32 +0100
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs The Natural Philosopher <tnp@invalid.invalid> - 2018-12-01 05:13 +0000
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "Anonymous Remailer (austria)" <mixmaster@remailer.privacy.at> - 2018-11-18 06:23 +0100
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-11-19 19:06 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Anonymous <anonymous@hoi-polloi.org> - 2018-11-19 21:44 +0100
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <nobody@dizum.com> - 2018-11-20 10:19 +0100
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Dave Froble <davef@tsoft-inc.com> - 2018-11-19 18:44 -0500
            Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs kludge@panix.com (Scott Dorsey) - 2018-11-19 19:00 -0500
              Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Bobbie Sellers <bliss@mouse-potato.com> - 2018-11-26 20:40 -0800
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Nomen Nescio <nobody@dizum.com> - 2018-11-20 10:09 +0100
      Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs fr314159@gmail.com - 2018-11-28 07:26 -0800
        Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Jasen Betts <jasen@xnet.co.nz> - 2018-11-29 19:45 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs Melzzzzz <Melzzzzz@zzzzz.com> - 2018-11-29 20:21 +0000
          Re: Linux 4.20 is Running Slower Than 4.19 On Intel CPUs "F. Russell" <fr@random.info> - 2018-11-29 20:26 +0000

Page 1 of 3  [1] 2 3  Next page →

#51696 — Linux 4.20 is Running Slower Than 4.19 On Intel CPUs

<https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>

[toc] | [next] | [standalone]

#51711

On 11/17/18 3:21 AM, Nomen Nescio wrote:
> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
> 

And it will run slower in the future as more and more serious security
vulnerabilities are found in intel hardware which then has to be fixed
in software.

The only CPU which seems to have been safe to use has been RISC-V, just
hope we will see desktop grade CPU's soon.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#51713

On 17/11/2018 11.10, J.O. Aho wrote:
> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>
> 
> And it will run slower in the future as more and more serious security
> vulnerabilities are found in intel hardware which then has to be fixed
> in software.
> 
> The only CPU which seems to have been safe to use has been RISC-V, just
> hope we will see desktop grade CPU's soon.

Well, possibly the smaller the instruction set, the less danger of
fucking up.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#51714

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 17/11/2018 11.10, J.O. Aho wrote:
>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>
>> 
>> And it will run slower in the future as more and more serious security
>> vulnerabilities are found in intel hardware which then has to be fixed
>> in software.
>> 
>> The only CPU which seems to have been safe to use has been RISC-V, just
>> hope we will see desktop grade CPU's soon.

Lots of other older CPUs are also immune to this attack class, they’re
just very slow by modern standards.

> Well, possibly the smaller the instruction set, the less danger of
> fucking up.

It’s not really anything to do with the size of the instruction set. The
microarchitectural attacks are essentially about how the instruction set
is implemented efficiently (mostly in time terms although the AVX warmup
sidechannel depends on a power usage optimization).

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#51721

On 17/11/2018 12.53, Richard Kettlewell wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
>> On 17/11/2018 11.10, J.O. Aho wrote:
>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>>
>>>
>>> And it will run slower in the future as more and more serious security
>>> vulnerabilities are found in intel hardware which then has to be fixed
>>> in software.
>>>
>>> The only CPU which seems to have been safe to use has been RISC-V, just
>>> hope we will see desktop grade CPU's soon.
> 
> Lots of other older CPUs are also immune to this attack class, they’re
> just very slow by modern standards.
> 
>> Well, possibly the smaller the instruction set, the less danger of
>> fucking up.
> 
> It’s not really anything to do with the size of the instruction set. The
> microarchitectural attacks are essentially about how the instruction set
> is implemented efficiently (mostly in time terms although the AVX warmup
> sidechannel depends on a power usage optimization).

I don't mean exactly that the size is involved, but that fewer
instructions and less complex instructions probably produce less
complexity of the chip itself and fewer chances of errors. The
complexity goes to the kernel and applications instead, but these can be
corrected, whereas the cpu itself can't (some parts can, firmware updates).

Just an educated guess :-)


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#51724

Carlos E.R. wrote:
> On 17/11/2018 12.53, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 17/11/2018 11.10, J.O. Aho wrote:
>>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>>>
>>>> And it will run slower in the future as more and more serious security
>>>> vulnerabilities are found in intel hardware which then has to be fixed
>>>> in software.
>>>>
>>>> The only CPU which seems to have been safe to use has been RISC-V, just
>>>> hope we will see desktop grade CPU's soon.
>> Lots of other older CPUs are also immune to this attack class, they’re
>> just very slow by modern standards.
>>
>>> Well, possibly the smaller the instruction set, the less danger of
>>> fucking up.
>> It’s not really anything to do with the size of the instruction set. The
>> microarchitectural attacks are essentially about how the instruction set
>> is implemented efficiently (mostly in time terms although the AVX warmup
>> sidechannel depends on a power usage optimization).
> 
> I don't mean exactly that the size is involved, but that fewer
> instructions and less complex instructions probably produce less
> complexity of the chip itself and fewer chances of errors. The
> complexity goes to the kernel and applications instead, but these can be
> corrected, whereas the cpu itself can't (some parts can, firmware updates).
> 
> Just an educated guess :-)

https://forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

But with so many exploit cases being created, I wonder if
these articles are still valid.

You could run on a Pi 3 then, for that "feeling of speed".

Plus, think of the electricity you'll save.

    Paul

[toc] | [prev] | [next] | [standalone]

#51788

Paul <nospam@needed.invalid> writes:

>
> https://forum.level1techs.com/t/list-of-cpus-most-likely-immune-to-spectre/123128
>
> https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/
>
> But with so many exploit cases being created, I wonder if
> these articles are still valid.
>
> You could run on a Pi 3 then, for that "feeling of speed".
>
> Plus, think of the electricity you'll save.

I have an Odroid XU4 that I use for some things, and it wouldn't take
much to make it into a computer that could replace a desktop for me.

It's also somehow really satisfying to use a computer that's this small
and uses so little power, but is more capable than many far larger
computers I've used in the past.

[toc] | [prev] | [next] | [standalone]

#51725

On 11/18/18 9:06 PM, Carlos E.R. wrote:
> On 17/11/2018 12.53, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 17/11/2018 11.10, J.O. Aho wrote:
>>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>>>
>>>>
>>>> And it will run slower in the future as more and more serious security
>>>> vulnerabilities are found in intel hardware which then has to be fixed
>>>> in software.
>>>>
>>>> The only CPU which seems to have been safe to use has been RISC-V, just
>>>> hope we will see desktop grade CPU's soon.
>>
>> Lots of other older CPUs are also immune to this attack class, they’re
>> just very slow by modern standards.
>>
>>> Well, possibly the smaller the instruction set, the less danger of
>>> fucking up.
>>
>> It’s not really anything to do with the size of the instruction set. The
>> microarchitectural attacks are essentially about how the instruction set
>> is implemented efficiently (mostly in time terms although the AVX warmup
>> sidechannel depends on a power usage optimization).
> 
> I don't mean exactly that the size is involved, but that fewer
> instructions and less complex instructions probably produce less
> complexity of the chip itself and fewer chances of errors. The
> complexity goes to the kernel and applications instead, but these can be
> corrected, whereas the cpu itself can't (some parts can, firmware updates).

It's been more about the speculative execution than the instructions
themselves, in Intel's drive to have the "fastest" CPU's they made
shortcuts which resulted in that their CPU's have been more vulnerable
to Meltdown and Spectre than other CPU's from AMD and Arm-family, which
both have been affected by the vulnerabilities too.

The whole idea with speculative execution is that it's better to start
doing something that seems to be needed to be done in the future, in
worst case you just throw away the result if not needed, but as the
thrown away data ain't protected it's possible to in one way or another
to get access to the data. If you disable the speculative execution,
then the CPU will do it's job slower and some of the fixes are to
disable the use of speculative execution and the more Intel related such
you find, the risk is that it will execute things even slower unless you
are prepared to have an insecure system.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#51727

"Carlos E.R." <robin_listas@es.invalid> writes:
> On 17/11/2018 12.53, Richard Kettlewell wrote:
>> "Carlos E.R." <robin_listas@es.invalid> writes:
>>> On 17/11/2018 11.10, J.O. Aho wrote:
>>>> On 11/17/18 3:21 AM, Nomen Nescio wrote:
>>>>> <https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1>
>>>> And it will run slower in the future as more and more serious security
>>>> vulnerabilities are found in intel hardware which then has to be fixed
>>>> in software.
>>>>
>>>> The only CPU which seems to have been safe to use has been RISC-V, just
>>>> hope we will see desktop grade CPU's soon.
>> 
>> Lots of other older CPUs are also immune to this attack class, they’re
>> just very slow by modern standards.
>> 
>>> Well, possibly the smaller the instruction set, the less danger of
>>> fucking up.
>> 
>> It’s not really anything to do with the size of the instruction set. The
>> microarchitectural attacks are essentially about how the instruction set
>> is implemented efficiently (mostly in time terms although the AVX warmup
>> sidechannel depends on a power usage optimization).
>
> I don't mean exactly that the size is involved, but that fewer
> instructions and less complex instructions probably produce less
> complexity of the chip itself and fewer chances of errors. The
> complexity goes to the kernel and applications instead, but these can be
> corrected, whereas the cpu itself can't (some parts can, firmware updates).
>
> Just an educated guess :-)

A wrong one, in this case. The Spectre class vulnerabilities are simply
not related to instruction set size. They are not errors in the
implementation of any instruction, they are consequences of whole-core
optimization strategies.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#51728

On 18/11/2018 20:06, Carlos E.R. wrote:
> I don't mean exactly that the size is involved, but that fewer
> instructions and less complex instructions probably produce less
> complexity of the chip itself and fewer chances of errors. The
> complexity goes to the kernel and applications instead, but these can be
> corrected, whereas the cpu itself can't (some parts can, firmware updates).
> 
> Just an educated guess:-)

Howver not as far as I know a correct one.

Thse CPU bugs are all about caching.

Caching menas you dont need to access main RAM so much and gives 
dramatic incerases in speed.

The bugs are as I understand it intrinsicv to the way caching is done on 
many chips.

Why we caqnnot have a switch to use the caching bugs and all on desktop 
machines that are behind firewalls is another matter

-- 
Canada is all right really, though not for the whole weekend.

"Saki"

[toc] | [prev] | [next] | [standalone]

#51730

On 11/19/18 7:33 PM, The Natural Philosopher wrote:

> Why we caqnnot have a switch to use the caching bugs and all on desktop
> machines that are behind firewalls is another matter

So you mean all behind a firewall will not interact with the internet in
any form? All data exchange is done over USB and hope no one is
utilizing the vulnerabilities regarding USB.

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#51742

On 19/11/2018 20:02, J.O. Aho wrote:
> On 11/19/18 7:33 PM, The Natural Philosopher wrote:
> 
>> Why we caqnnot have a switch to use the caching bugs and all on desktop
>> machines that are behind firewalls is another matter
> 
> So you mean all behind a firewall will not interact with the internet in
> any form? All data exchange is done over USB and hope no one is
> utilizing the vulnerabilities regarding USB.
> 
At least behind a firewall if you get hit by a nasty its you that 
initiated the activity

AIUI the bug requires at least user level (machine) code running on the 
target

So java or javascript wont cut the mustard. I.e. you have to download 
and install some 'compiled'  malware..

I may be wrong but thats how I thought it worked

Amd that means probably a compromised distro source - but if that is the 
case then as we have found with systemd, root level malware can be 
installed anyway.


-- 
To ban Christmas, simply give turkeys the vote.

[toc] | [prev] | [next] | [standalone]

#51743

On 11/20/18 5:46 AM, The Natural Philosopher wrote:
> On 19/11/2018 20:02, J.O. Aho wrote:
>> On 11/19/18 7:33 PM, The Natural Philosopher wrote:
>>
>>> Why we caqnnot have a switch to use the caching bugs and all on desktop
>>> machines that are behind firewalls is another matter
>>
>> So you mean all behind a firewall will not interact with the internet in
>> any form? All data exchange is done over USB and hope no one is
>> utilizing the vulnerabilities regarding USB.
>>
> At least behind a firewall if you get hit by a nasty its you that
> initiated the activity
> 
> AIUI the bug requires at least user level (machine) code running on the
> target

Yes, a browser it run as user...


> So java or javascript wont cut the mustard. I.e. you have to download
> and install some 'compiled'  malware..

Sorry but javascript is enough
https://react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript


> Amd that means probably a compromised distro source - but if that is the
> case then as we have found with systemd, root level malware can be
> installed anyway.

Things could get even worse when the malware is installed on the CPU
http://www.eweek.com/security/newly-revealed-flaw-in-intel-processors-allows-undetectable-malware


-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#51736

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 18/11/2018 20:06, Carlos E.R. wrote:
> 
> Why we caqnnot have a switch to use the caching bugs and all on desktop 
> machines that are behind firewalls is another matter

I gathered from the follow-up article to the one posted (sorry too
lazy to get the link, it's at the end of the second page), that it
must be possible to disable at least the most performance significant
bug "fixes", because he compares the same kernel with and without
them enabled. No idea whether that's set at compile time or is a
run-time option.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#51737

On Mon, 19 Nov 2018 16:58:52 -0500, Computer Nerd Kev <not@telling.you.invalid> wrote:

> I gathered from the follow-up article to the one posted (sorry too
> lazy to get the link, it's at the end of the second page), that it
> must be possible to disable at least the most performance significant
> bug "fixes", because he compares the same kernel with and without
> them enabled. No idea whether that's set at compile time or is a
> run-time option.

See /usr/share/doc/kernel-doc/admin-guide/kernel-parameters.txt for the boot
time parameters to disable the mitigations. Just search through the text
file for the word mitigation. The kernel boot parameter
nospec_store_bypass_disable should disable most of them, at your own risk.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#51738

On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher <tnp@invalid.invalid> wrote:

> Thse CPU bugs are all about caching.

Not quite all. The meltdown class of bugs are about caching, but the
spectre class bugs are about speculative execution.
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

For maximum safety, disable execution on all but one core/thread. :-(

For maximum performance, disable the mitigations with the boot parameters
documented in the kernel-parameters.txt such as nospec_store_bypass_disable.

For normal use, get used to the slightly lower performance of some
applications.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#51747

"David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> Thse CPU bugs are all about caching.

Not really. There are variants that don’t depend on the cache at all.

> Not quite all. The meltdown class of bugs are about caching, but the
> spectre class bugs are about speculative execution.
> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Both involve speculation. In Meltdown the CPU speculates past an
exception; in Spectre, past a branch.

The original versions of both do involve the cache, as the channel for
exfiltration of secrets. However that’s not the only possible side
channel. For example, https://arxiv.org/pdf/1807.10535.pdf describes an
AVX powerup side channel.

-- 
https://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#51751

On Tue, 20 Nov 2018 10:10:45 +0000, Richard Kettlewell wrote:
>
> "David W. Hodgins" <dwhodgins@nomail.afraid.org> writes:
>
>> Not quite all. The meltdown class of bugs are about caching, but the
>> spectre class bugs are about speculative execution.
>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>
> Both involve speculation. In Meltdown the CPU speculates past an
> exception; in Spectre, past a branch.
>
> The original versions of both do involve the cache, as the channel for
> exfiltration of secrets. However that’s not the only possible side
> channel. For example, https://arxiv.org/pdf/1807.10535.pdf describes an
> AVX powerup side channel.

No one talking about Portshmash
<https://www.zdnet.com/article/intel-cpus-impacted-by-new-portsmash-side-channel-vulnerability/>
here? Not quite the same, but you could leak encrypted data. Until there
is a patch the deactivation of Multi-Threading is suggested.
-- 
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

[toc] | [prev] | [next] | [standalone]

#51752

In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher <tnp@invalid.invalid> wrote:
> 
>> Thse CPU bugs are all about caching.
> 
> Not quite all. The meltdown class of bugs are about caching, but the
> spectre class bugs are about speculative execution.
> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
> 
> For maximum safety, disable execution on all but one core/thread. :-(

I don't think that would do. The Pentium Pro was apparantly the first
Intel x86 CPU to support speculative execution, and it was only
available as a single-core CPU. The speculatively executed
instructions can be done with a single core while it's waiting for
a memory read or similar.

-- 
__          __
#_ < |\| |< _#

[toc] | [prev] | [next] | [standalone]

#51753

In comp.os.linux.misc Computer Nerd Kev <not@telling.you.invalid> wrote:
> In comp.os.linux.misc David W. Hodgins <dwhodgins@nomail.afraid.org> wrote:
>> On Mon, 19 Nov 2018 13:33:17 -0500, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> 
>>> Thse CPU bugs are all about caching.
>> 
>> Not quite all. The meltdown class of bugs are about caching, but the
>> spectre class bugs are about speculative execution.
>> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
>> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>> 
>> For maximum safety, disable execution on all but one core/thread. :-(
> 
> I don't think that would do. The Pentium Pro was apparantly the first
> Intel x86 CPU to support speculative execution, and it was only
> available as a single-core CPU. The speculatively executed
> instructions can be done with a single core while it's waiting for
> a memory read or similar.

Speculative execution has never required plural cores.  It has always 
been about keeping a CPU's execution units busy doing something when 
they would otherwise be idle, in the expectation that at least part of 
the time the extra work done would need to be done anyway and the CPU 
would be ahead of where it otherwise would have been had it simply idle 
waited.

Padding over memory latency was an early driver for building 
speculative execution into CPU's [1] .  Another driver was as single CPU 
pipelines grew larger, the loss from a pipeline flush/refill became 
ever larger, so speculative execution was also used to try to keep the 
pipeline full with something, hoping that part of the time it was the 
right something.

Much of the refinements that Intel and others have added is not so much 
to enhance 'speculative execution' itself, but instead are refinements 
to better predict just exactly "which" instructions will be needed with 
ever greater accuracy so that the ratio of "yes, needed to do anyway" 
vs.  "no, did not need" grew much larger on the "yes" side of the 
equation.

[1] This did need an i-cache, because reading speculative instructions 
from the same memory you are already idle waiting upon to respond to a 
data read generally did not work out well.


The cause of the Meltdown/Spectre issues is that the intersection of 
CPU architects with cryptographers familiar with side channel attacks 
is effectively zero, and so none of the CPU architects were aware that 
tiny differences in timing caused by speculative code execution could 
be used to obtain unrelated or protected information.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web