Time to look for a kernel update...

classic Classic list List threaded Threaded
98 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Time to look for a kernel update...

Roger Oberholtzer-2
http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/


--
Roger Oberholtzer

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

L A Walsh
Roger Oberholtzer wrote:
> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>  
* Affects all "modern" 64-bit Intel processors, though some
  newer "modern" chips might have some instruction to further
  limit potential impact
* Fix in kernel software (Apple, Linux; Windows) instead of
  HW results in a 5-30% or 17-23% slowdown on EVERY system call
* Not exploitable in itself, but could allow easier exploits
  against other kernel features like the library address space
  randomization.
* need to be have a hostile program running on system to be abusable,
  including processes running in VM's, including many or most Cloud
  implementations (ex. Amazon EC2 and Google Compute Engine)

** side note: It doesn't appear developers are considering a "don't care"
  fix  applicable where someone doesn't want a ~20% speed slowdown on
  syscalls and isn't running hostile code, even in a VM.
  This would apply to most non-cloud, end-user systems.

* For good measure, similar software protections will be included
  on 64-bit ARM kernels as well;  While AMD chips aren't affected
  by this bug, it's hard to see an update physically-splitting
  (instead of just virtually-splitting) all kernel & user code,
  only being applied against Intel and ARM (i.e. AMD chip-based systems
  may likely be affected by the slowdown due to the fix being applied
  across 64-bit kernels.


--------

Of course, Intel hasn't stepped up to say they'll replace the faulty
chips, which seem to be related mostly to Intel-specific chip speedups
not in other chips (like Intel's "speculative execution" feature that
pre-executes multiple branches of a conditional ahead of knowing which
branch will be taken).  Intel has a history of offering replacing HW or
compensation for their chips being hit by a 20% perf-penalty in the
field.

Lovely...
-l







--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Carlos E. R.-2
On 2018-01-03 17:48, Linda Walsh wrote:

>
> * For good measure, similar software protections will be included
>  on 64-bit ARM kernels as well;  While AMD chips aren't affected
>  by this bug, it's hard to see an update physically-splitting
>  (instead of just virtually-splitting) all kernel & user code,
>  only being applied against Intel and ARM (i.e. AMD chip-based systems
>  may likely be affected by the slowdown due to the fix being applied
>  across 64-bit kernels.

AMD has asked the measure not be applied to their processors.


Any method to know if /my/ processor is affected? It was bought several
years ago. A list of exact processor models for looking in
/proc/cpuinfo, perhaps.

> --------
>
> Of course, Intel hasn't stepped up to say they'll replace the faulty
> chips, which seem to be related mostly to Intel-specific chip speedups
> not in other chips (like Intel's "speculative execution" feature that
> pre-executes multiple branches of a conditional ahead of knowing which
> branch will be taken).  Intel has a history of offering replacing HW or
> compensation for their chips being hit by a 20% perf-penalty in the
> field.
>
> Lovely...
Indeed. :-/

I guess they don't have the kind of money needed.

--
Cheers / Saludos,

                Carlos E. R.
                (from 42.2 x86_64 "Malachite" at Telcontar)


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: chip sniffing (was "Re: [opensuse] time to pressure Intel ...")

David T-G-2
Carlos, et al --

...and then Carlos E. R. said...
%
...
% Any method to know if /my/ processor is affected? It was bought several
% years ago. A list of exact processor models for looking in
% /proc/cpuinfo, perhaps.
[snip]

That certainly would be a nice twist.  Suddenly all of those old chips
out there run faster than the fancy new whiz-bangs just because they
don't need the super-secure kernel shuffling :-)


Happy New Year

:-D
--
David T-G
See http://justpickone.org/davidtg/email/
See http://justpickone.org/davidtg/tofu.txt


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Christopher Myers-2
In reply to this post by Carlos E. R.-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On Wed, 2018-01-03 at 19:45 +0100, Carlos E. R. wrote:

> On 2018-01-03 17:48, Linda Walsh wrote:
>
> >
> > * For good measure, similar software protections will be included
> >  on 64-bit ARM kernels as well;  While AMD chips aren't affected
> >  by this bug, it's hard to see an update physically-splitting
> >  (instead of just virtually-splitting) all kernel & user code,
> >  only being applied against Intel and ARM (i.e. AMD chip-based
> > systems
> >  may likely be affected by the slowdown due to the fix being
> > applied
> >  across 64-bit kernels.
>
> AMD has asked the measure not be applied to their processors.
>

- From AMD's perspective, it would definitely be exasperating to have
your hardware penalized when you didn't screw stuff up... Surely
there's got to be some way to selectively enable the "protections"
based off of CPU model, like there is with other features?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE7GM/Dul8WSWn72odQ1nEo4DFCIUFAlpNL4MACgkQQ1nEo4DF
CIULPgf/Z6rFzxojdZpTwElm3hYtPfCfVblSqgfdfUqqbdmqqYH2mYP3YJow4Mwe
xRZlVyAWfnJUfqdpsbVlDGD1xDtcEHz+pd71gk2KkPZZxoTvPDrL4Zj4XaYAbMJl
AcJTGlpD95foM8IOVtSOXp7+jO97OkW/PLmFwAfdIJJSVJWvfBRnaR6Dn4FvtufA
7omT0yOBT03cKa/wiP9tyyNmk+hgZB0b0zzsEX3FM6VrIAMQ7utrCLR5VCX9kGQb
+ud2l7os58MUQV2H7ENGpL6POkBkdVaSeYB6aURR3kkfo7ZBB7cG1ODFaDSCjWAR
IYYoqmQxqRgpeXfpl42bBTR+JrBKxA==
=bVwN
-----END PGP SIGNATURE-----
N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�:�{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Wol's lists
On 03/01/18 19:31, Christopher Myers wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>
> On Wed, 2018-01-03 at 19:45 +0100, Carlos E. R. wrote:
>> > On 2018-01-03 17:48, Linda Walsh wrote:
>> >
>>> > >
>>> > > * For good measure, similar software protections will be included
>>> > >  on 64-bit ARM kernels as well;  While AMD chips aren't affected
>>> > >  by this bug, it's hard to see an update physically-splitting
>>> > >  (instead of just virtually-splitting) all kernel & user code,
>>> > >  only being applied against Intel and ARM (i.e. AMD chip-based
>>> > > systems
>>> > >  may likely be affected by the slowdown due to the fix being
>>> > > applied
>>> > >  across 64-bit kernels.
>> >
>> > AMD has asked the measure not be applied to their processors.
>> >
> - From AMD's perspective, it would definitely be exasperating to have
> your hardware penalized when you didn't screw stuff up... Surely
> there's got to be some way to selectively enable the "protections"
> based off of CPU model, like there is with other features?

You mean, like, compile your own kernels?

Actually, from what I've picked up there is a command-line kernel boot
option that will disable it even if compiled in.

But surely (I've never done it on S(uU)SE), you must be able to download
the kernel source package, disable it, and recompile?

Cheers,
Wol

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

John Andersen-2
In reply to this post by Christopher Myers-2
On 01/03/2018 11:31 AM, Christopher Myers wrote:
> From AMD's perspective, it would definitely be exasperating to have
> your hardware penalized when you didn't screw stuff up... Surely
> there's got to be some way to selectively enable the "protections"
> based off of CPU model, like there is with other features?

It was in a patch that exempted AMD processors submitted by an
AMD employee that the hint as to the root cause was found.

So the patch, already accepted, will do as you suggest.

--
After all is said and done, more is said than done.


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Yamaban
In reply to this post by Carlos E. R.-2
On Wed, 3 Jan 2018 19:45, Carlos E. R. <robin.listas@...> wrote:

> On 2018-01-03 17:48, Linda Walsh wrote:
>
>>
>> * For good measure, similar software protections will be included
>>  on 64-bit ARM kernels as well;  While AMD chips aren't affected
>>  by this bug, it's hard to see an update physically-splitting
>>  (instead of just virtually-splitting) all kernel & user code,
>>  only being applied against Intel and ARM (i.e. AMD chip-based systems
>>  may likely be affected by the slowdown due to the fix being applied
>>  across 64-bit kernels.
>
> AMD has asked the measure not be applied to their processors.
>
>
> Any method to know if /my/ processor is affected? It was bought several
> years ago. A list of exact processor models for looking in
> /proc/cpuinfo, perhaps.
AFAICT, if is has 'Core' in its name, its affected, as well as all
other Processor models of the last 6 years at least, talk is going
on on the older models, up to 10 years back is hit in certain models.

Check the better sources, e.g. the more serious computer publications
or proven to be better informed sources on the internet on details.

Root cause is a 'accelerated' branch pre-execution, in other words,
they dropped the security checks to gain speed.

My Haswell is hit by it for sure.
  - Yamaban
Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Marcus Meissner
In reply to this post by Roger Oberholtzer-2
Hi,

The advisories have just been published by the researchers.

http://meltdownattack.com/ / https://spectreattack.com/

SUSE has been aware of these problems and we are in the process
of preparing and soon releasing fixes.

Ciao, Marcus

On Wed, Jan 03, 2018 at 01:02:31PM +0100, Roger Oberholtzer wrote:

> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>
> --
> Roger Oberholtzer
>
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>

--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <[hidden email]>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

John Andersen-2
In reply to this post by John Andersen-2
On January 3, 2018 2:35:35 PM PST, Jones de Andrade <[hidden email]> wrote:

>On Wed, Jan 3, 2018 at 6:49 PM, John Andersen <[hidden email]>
>wrote:
>
>> On 01/03/2018 11:31 AM, Christopher Myers wrote:
>> > From AMD's perspective, it would definitely be exasperating to have
>> > your hardware penalized when you didn't screw stuff up... Surely
>> > there's got to be some way to selectively enable the "protections"
>> > based off of CPU model, like there is with other features?
>>
>> It was in a patch that exempted AMD processors submitted by an
>> AMD employee that the hint as to the root cause was found.
>>
>> So the patch, already accepted, will do as you suggest.
>>
>
>Important: at least accordingly to Intel, AMD is also affected:
>
>https://www.streetinsider.com/Corporate+News/Intel+%28INTC%29+Responds+to+Security+Research+Findings/13648696.html


Neither Intel, nor your linked article says AMD is affected.

Some ARM processors are. But AMD has specificly denied it.


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Basil Chupin-2
In reply to this post by Roger Oberholtzer-2
On 03/01/18 23:02, Roger Oberholtzer wrote:
> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Or is it a 'backdoor' which has been discovered only now?

BC

--
Always be nice to people on your way up -- you'll see
the same people on your way down.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Andrei Borzenkov
In reply to this post by John Andersen-2
04.01.2018 06:30, John Andersen пишет:

> On January 3, 2018 2:35:35 PM PST, Jones de Andrade <[hidden email]> wrote:
>> On Wed, Jan 3, 2018 at 6:49 PM, John Andersen <[hidden email]>
>> wrote:
>>
>>> On 01/03/2018 11:31 AM, Christopher Myers wrote:
>>>> From AMD's perspective, it would definitely be exasperating to have
>>>> your hardware penalized when you didn't screw stuff up... Surely
>>>> there's got to be some way to selectively enable the "protections"
>>>> based off of CPU model, like there is with other features?
>>>
>>> It was in a patch that exempted AMD processors submitted by an
>>> AMD employee that the hint as to the root cause was found.
>>>
>>> So the patch, already accepted, will do as you suggest.
>>>
>>
>> Important: at least accordingly to Intel, AMD is also affected:
>>
>> https://www.streetinsider.com/Corporate+News/Intel+%28INTC%29+Responds+to+Security+Research+Findings/13648696.html
>
>
> Neither Intel, nor your linked article says AMD is affected.
>
> Some ARM processors are. But AMD has specificly denied it.
>
>
There are multiple exploits. One apparently relies on what can be
considered hardware design and so it is possible that AMD is not
vulnerable. Others simply (ab-)use speculative instruction
execution/branch prediction and were PoC for Intel, AMD and ARM.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Basil Chupin-2
In reply to this post by Marcus Meissner
On 04/01/18 10:34, Marcus Meissner wrote:

> Hi,
>
> The advisories have just been published by the researchers.
>
> http://meltdownattack.com/ / https://spectreattack.com/
>
> SUSE has been aware of these problems and we are in the process
> of preparing and soon releasing fixes.
>
> Ciao, Marcus

My take on this is that nobody with a Nvidia GPU will be installing the
new kernel -- assuming that the 'fix' will be in the form of a new
kernel -- until the problem with compiling the nIvidia driver under the
>= 4.14.11 version is resolved.

BC

--
Always be nice to people on your way up -- you'll see
the same people on your way down.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Andrei Borzenkov
04.01.2018 09:55, Basil Chupin пишет:

> On 04/01/18 10:34, Marcus Meissner wrote:
>> Hi,
>>
>> The advisories have just been published by the researchers.
>>
>> http://meltdownattack.com/ / https://spectreattack.com/
>>
>> SUSE has been aware of these problems and we are in the process
>> of preparing and soon releasing fixes.
>>
>> Ciao, Marcus
>
> My take on this is that nobody with a Nvidia GPU will be installing the
> new kernel -- assuming that the 'fix' will be in the form of a new
> kernel -- until the problem with compiling the nIvidia driver under the
>> = 4.14.11 version is resolved.
>
> BC
>

And you point is?

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Roger Oberholtzer-2
In reply to this post by Basil Chupin-2
On Thu, Jan 4, 2018 at 7:55 AM, Basil Chupin <[hidden email]> wrote:

> My take on this is that nobody with a Nvidia GPU will be installing the
> new kernel -- assuming that the 'fix' will be in the form of a new
> kernel -- until the problem with compiling the nIvidia driver under the
>>= 4.14.11 version is resolved.

We have stayed with the nouveau driver, so I guess a new kernel will
be possible.

For Leap 42.3, will the patch be applied to the 4.4.92 kernel? At
least that is what I have installed.

My bigger concern is the speed penalty. Our applications are very
network and I/O bound (meaning lots of system calls). I wonder what
the effect will be. There were mentions of up to a 10% speed penalty.
I hope our use does not suffer that.

My own computer has an AMD CPU. I guess it is not effected. But our
production systems are all intel. We're just waiting for the list of
effected CPU models to be released.

--
Roger Oberholtzer

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Basil Chupin-2
In reply to this post by Andrei Borzenkov
On 04/01/18 18:53, Andrei Borzenkov wrote:

> 04.01.2018 09:55, Basil Chupin пишет:
>> On 04/01/18 10:34, Marcus Meissner wrote:
>>> Hi,
>>>
>>> The advisories have just been published by the researchers.
>>>
>>> http://meltdownattack.com/ / https://spectreattack.com/
>>>
>>> SUSE has been aware of these problems and we are in the process
>>> of preparing and soon releasing fixes.
>>>
>>> Ciao, Marcus
>> My take on this is that nobody with a Nvidia GPU will be installing the
>> new kernel -- assuming that the 'fix' will be in the form of a new
>> kernel -- until the problem with compiling the nIvidia driver under the
>>> = 4.14.11 version is resolved.
>> BC
>>
> And you point is?

Ce`?

BC

--
Always be nice to people on your way up -- you'll see
the same people on your way down.



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Carlos E. R.-2
In reply to this post by Yamaban
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:

> On Wed, 3 Jan 2018 19:45, Carlos E. R. <robin.listas@...> wrote:


>>  Any method to know if /my/ processor is affected? It was bought several
>>  years ago. A list of exact processor models for looking in
>>  /proc/cpuinfo, perhaps.
>
> AFAICT, if is has 'Core' in its name, its affected, as well as all
> other Processor models of the last 6 years at least, talk is going
> on on the older models, up to 10 years back is hit in certain models.

Core 2 Duo, so yes, I'm hit.


> Check the better sources, e.g. the more serious computer publications
> or proven to be better informed sources on the internet on details.

Links will pop up in time :-)


> Root cause is a 'accelerated' branch pre-execution, in other words,
> they dropped the security checks to gain speed.

Yes, that part I found out.

Intentionally? They forgot? Ineptitude?
Did they really think they would not be found out?
Sigh :-(

- --
Cheers,
        Carlos E. R.
        (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlpOIogACgkQtTMYHG2NR9V1zgCfYLafeqlzFFZ6P3MB7Uj8XAmj
zPgAn1pm+mQ5Aq4dR/+ZrmtKsKQlQLkU
=jiwx
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Time to look for a kernel update...

Carlos E. R.-2
In reply to this post by Basil Chupin-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Thursday, 2018-01-04 at 17:30 +1100, Basil Chupin wrote:

> On 03/01/18 23:02, Roger Oberholtzer wrote:
>> http://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
> Or is it a 'backdoor' which has been discovered only now?

Second person I see asking that ;-)

I doubt it. A backdoor is done subtly, and you need to control it (meaning
you need to protect yourself, enable/disable at will).

This thing affects all computers, even those on "your" side. So yes, you
may attack others, and they can attack you back. You can not be sure the
bad guys and intelligence agencies don't find about about this. There is
no way you can secure your own computer, you need a redesign of the kernel
in a way that affects speed: not something you want for yourself.

- --
Cheers,
        Carlos E. R.
        (from openSUSE 42.2 x86_64 "Malachite" at Telcontar)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlpOI7cACgkQtTMYHG2NR9WibQCdHBatvcyWQC6JMKzhUE95f84G
SZoAmwWtWf+z0uBbo7UcLE1CRAWPSonn
=KZe/
-----END PGP SIGNATURE-----

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Yamaban
In reply to this post by Carlos E. R.-2
On Thu, 4 Jan 2018 13:48, Carlos E. R. wrote:

> On Wednesday, 2018-01-03 at 23:48 +0100, Yamaban wrote:
>
>> On Wed, 3 Jan 2018 19:45, Carlos E. R. wrote:
>
>
>>>  Any method to know if /my/ processor is affected? It was bought several
>>>  years ago. A list of exact processor models for looking in
>>>  /proc/cpuinfo, perhaps.
>>
>> AFAICT, if is has 'Core' in its name, its affected, as well as all
>> other Processor models of the last 6 years at least, talk is going
>> on on the older models, up to 10 years back is hit in certain models.
>
> Core 2 Duo, so yes, I'm hit.
>
>
>> Check the better sources, e.g. the more serious computer publications
>> or proven to be better informed sources on the internet on details.
>
> Links will pop up in time :-)
>
>
>> Root cause is a 'accelerated' branch pre-execution, in other words,
>> they dropped the security checks to gain speed.
>
> Yes, that part I found out.
>
> Intentionally? They forgot? Ineptitude?
> Did they really think they would not be found out?
> Sigh :-(

Well, no. "The Issue" dated back to the development of the "Pentium Pro",
the 32bit dual-core Pentium  from 1995.

Intel found out the hard way that the branch prediction engine they
planned to include was a mass grave of transistors, thus immensely
expensive and drove the already low yield of the production down to
single digits of percents.
So, to get even a kind of a grip at the situation, the whole branch
prediction engine was re-designed. Much simpler, used less  cycles,
used not even a tenth of the transistors. Intel hyped that as
"Productivity Enhanced" Branch Prediction in the pre-release days.

The documentation of the Pentium Pro clearly stated the restrictions the
reduced branch prediction unit had, and the compilers at the time
handled that with the needed care.

Fast forward to around 2005, the race between Intel and AMD got "not nice"
and thus Intel "optimised" its own compiler to reduce the prior as
"must have" declared security checks to gain speed.
In the name of performance over everything else this kind of optimisation
found its way into other code. Databases, OS-kernels, compilers.
You can easily do the math. Using a non paranoid compiler opens you up the
the holes now published (they where found before October 2017).
(Much of the harshness of the situation is the dramatically risen level
  of visualisation compared to ten years ago.)

So, much to late for Intel or AMD to include a hardware based defence
into the latest architectures (that needs at least 15 month lead time)

Will Intel's next Arch (Core i{3,5,7,9}-9yyy) have such a defence?
More likely no, same with AMD and ARM.

At the base we are left with dropped security checks and left out early
randomisation for context changes and other heavy lifting stuff in nearly
very bit of code, simply because there are very little people left that
can program such check without opening wide the doors for much more ugly
attacks.

The TODO now is to redefine "best (and/or) acceptable practises in coding
for such situations.

The fastest way to get the redefined message out would be compilers that
will not accept code that violates such "best practises" easily.

Will we see a real break-through on that matter in 2018?
  - My gut tells me: NO real chance, just some small steps
    (with performance penalties).

So, pressing anyone for replacemnt hardware: Prepare to be laughed out of
the doors, while fingers are pointed to the compiler guys.

  - Yamaban.

PS: If I've got stuff wrong, please speak out with the truth.
I'm no god, nor otherwise omnipotent.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: time to pressure Intel for a chip replacement (was Re: Time to look for a kernel update...)

Liam Proven
On Thu, 4 Jan 2018 17:47:28 +0100 (CET)
Yamaban <[hidden email]> wrote:

> Well, no. "The Issue" dated back to the development of the "Pentium Pro",
> the 32bit dual-core Pentium  from 1995.
>
> Intel found out the hard way that the branch prediction engine they
> planned to include was a mass grave of transistors, thus immensely
> expensive and drove the already low yield of the production down to
> single digits of percents.
> So, to get even a kind of a grip at the situation, the whole branch
> prediction engine was re-designed. Much simpler, used less  cycles,
> used not even a tenth of the transistors. Intel hyped that as
> "Productivity Enhanced" Branch Prediction in the pre-release days.
>
> The documentation of the Pentium Pro clearly stated the restrictions the
> reduced branch prediction unit had, and the compilers at the time
> handled that with the needed care.
>
> Fast forward to around 2005, the race between Intel and AMD got "not nice"
> and thus Intel "optimised" its own compiler to reduce the prior as
> "must have" declared security checks to gain speed.
> In the name of performance over everything else this kind of optimisation
> found its way into other code. Databases, OS-kernels, compilers.
> You can easily do the math. Using a non paranoid compiler opens you up the
> the holes now published (they where found before October 2017).
> (Much of the harshness of the situation is the dramatically risen level
>   of visualisation compared to ten years ago.)

I am not a world-class expert in this, but I was watching and writing about this tech at the time. I have not heard about the details you're talking about here. Note, please, I am not saying you're wrong!

There was a significant step that you don't mention though.

The Pentium Pro was the first Intel micro-architecture (called P6) to break down instructions into micro-operations and do out-of-order execution on them (AFAICR.) The Pentium Pro was the basis of the Pentium II and Pentium III, with essentially the same P6 architecture.

The Pentium 4 was a new chip with a new architecture, Netburst. Notably, along with everything else, it had an all-new branch-prediction unit.

It was famous for high clock speeds, low instructions-per-clock (IPC) rate, running very hot and generally not being a great CPU family.

AMD's Sledgehammer architecture (Athlon 64/Opteron) thrashed it.

So, Intel Israel got the job of designing a successor. They produced the Pentium M low-power-draw chip for laptops: a P6 core, but on the new bus of the Pentium 4 and with Netburst's improved branch prediction unit.

It had good IPC, ran cool, and was a success.

Around the same time, Intel India was working on quad-core P4 CPUs. Due to violating Intel's strict policies on nepotism and cronyism, Intel India was shut down, meaning the end of the planned future line of Netburst CPUs.

Intel switched emphasis to the Pentium M. Intel Texas got the job of updating the P4 line with dual-core models (2 separate CPU dies in 1 package) and with adapting AMD's 64-bit instruction set extensions.

(Intel had devised its own x86-64 extension but Microsoft vetoed it. MS said it was already supporting x86-32, Itanium and AMD64, and would not additionally support another 64-bit instruction set architecture. Intel scrapped its own x86-64 ISA and implemented AMD's instead.)

Meanwhile, Intel Israel enhanced the Pentium M to produce the 32-bit Core processors, and then those were enhanced to support AMD64, creating the Core 2 series. Netburst was discontinued, in a huge, humiliating and very expensive climb-down and turnaround for Intel.

AFAICT, the Core series was where what's now being called Meltdown began.

I.e. with the incorporation of the Netburst branch-prediction unit into a descendant of the P6 microarchitecture.


--
Liam Proven - Technical Writer, SUSE Linux s.r.o.
Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia
Email: [hidden email] - Office telephone: +420 284 241 084



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12345