Intel junk...Kernel-memory-leaking Intel processor design flaw forcesLinux, Windows redesign

Den 2018-01-06 kl. 16:27, skrev Alan Browne:
On 2018-01-05 16:00, DaveFroble wrote:
Alan Browne wrote:
On 2018-01-05 09:15, DaveFroble wrote:
Jan-Erik Soderholm wrote:

Becuse the designers, for performance reasons, has mapped kernel memory
into the user process address space and relies on the OS to check
protection before any kernel memory (or code) is accessed.

The issue with the current issues is that the hardware (the CPU) does
these accesses in hardware "under the hood" without control by the OS.

If you map your kernel memory in another way that uses the hardware
protection facilities, you are (as I understand) safe, at the cost
of worse performance to switch between user and kernel mode.



As I wrote, someone dropped the ball on this one.

Speculative execution is part of the HW, not software.Â* It appears the
HW doesn't follow it's own rules.Â* Or, perhaps I don't actually
understand the problem?

At least as well as I do.Â* These are very complex mechanisms and
complexity is usually where you're most likely to get problems.

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.


There seems a whole bunch of us "speculating" about things we probably
don't know enough about.

I am very certain that they either did not design the testing correctly or
didn't test per the test plan correctly.Â* Or a bad scenario: they saw it
and carpeted it.


:-)

It seems to me that before memory is fetched into cache, the CPU should
be determining whether it should indeed be fetching that memory.Â* Yeah,

The CPU memory controller is (usually) the arbiter of whether a fetch is
"legal" in the privilege scheme - so if something is allowed to be fetched,
then it is fetched.Â* So (hierarchically) the fetch goes to the decoding
pipeline(s) -and- is simultaneously copied to the cache.Â* At that point the
MC has "allowed" the fetch.Â* Writes to memory are also written to cache.
The issue seems to be that post fetch from Kernel assigned memory, the
cache makes some privileged data available to lower priority tasks after
the context switch.Â* That is the gist.


As I understand, the CPU fetched prived data "under the hood" even before
the processor has decided that it was prived data. When the user process
get an "slap on the hand", the tracks was already in the cache.

There was never any "context switch" involved at all, it was way below
such constructs. Everything was done from user level "under the radar"
from the point of view of the any OS (or the protection facilities in
the CPU itself, it also seems).

And it never made any priviledge data avalable at all. It used the prived
data (byte) that was pre-fetched as an index into an array in user memory
and could later identify what element of the user data that was touched.

Clever...






sounds simple, but I'm betting it isn't.

I recall when pipelining came to simple microprocessors and we were in the
lab swapping processors and measuring the performance gains and salivating
over not much... or IIRC a competitor to the 8088 came out with some cycles
saved on some instructions and we were doing the same thing.Â* Then
pre-fetching came - then predictive decoding and so on ...

What they do these days in processors in mind-boggling layers of complexity
before you even get close to privilege management.

To me though, multicore processing is the best achievement.Â* Certainly
makes OS's and apps very smooth in operation.

On 2018-01-06 10:53, Pabst Blue Ribbon wrote:
Alan Browne wrote:
On 2018-01-05 18:01, Pabst Blue Ribbon wrote:
Alan Browne wrote:

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.

I doubt it. Yes, it's assumption but I think Intel was aware and gave OK to
flawed design because of performance/cost.

Possible, but I'd discount a deliberate pass. FDIV was very costly to
intel - this could be much more costly if the class action suits start
flying due to increased computing costs and so on.


"Could be much more costly" didn't stop Volkswagen.

Easy toss. Doesn't prove anything wrt intel.

--
“When it is all said and done, there are approximately 94 million
full-time workers in private industry paying taxes to support 102
million non-workers and 21 million government workers.
In what world does this represent a strong job market?�
..Jim Quinn

On 2018-01-06 11:06, Jan-Erik Soderholm wrote:
Den 2018-01-06 kl. 16:27, skrev Alan Browne:
On 2018-01-05 16:00, DaveFroble wrote:
Alan Browne wrote:
On 2018-01-05 09:15, DaveFroble wrote:
Jan-Erik Soderholm wrote:

Becuse the designers, for performance reasons, has mapped kernel
memory
into the user process address space and relies on the OS to check
protection before any kernel memory (or code) is accessed.

The issue with the current issues is that the hardware (the CPU) does
these accesses in hardware "under the hood" without control by the
OS.

If you map your kernel memory in another way that uses the hardware
protection facilities, you are (as I understand) safe, at the cost
of worse performance to switch between user and kernel mode.



As I wrote, someone dropped the ball on this one.

Speculative execution is part of the HW, not software.Â* It appears
the HW doesn't follow it's own rules.Â* Or, perhaps I don't actually
understand the problem?

At least as well as I do.Â* These are very complex mechanisms and
complexity is usually where you're most likely to get problems.

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.


There seems a whole bunch of us "speculating" about things we
probably don't know enough about.

I am very certain that they either did not design the testing
correctly or didn't test per the test plan correctly.Â* Or a bad
scenario: they saw it and carpeted it.


:-)

It seems to me that before memory is fetched into cache, the CPU
should be determining whether it should indeed be fetching that
memory.Â* Yeah,

The CPU memory controller is (usually) the arbiter of whether a fetch
is "legal" in the privilege scheme - so if something is allowed to be
fetched, then it is fetched.Â* So (hierarchically) the fetch goes to
the decoding pipeline(s) -and- is simultaneously copied to the cache.
At that point the MC has "allowed" the fetch.Â* Writes to memory are
also written to cache. The issue seems to be that post fetch from
Kernel assigned memory, the cache makes some privileged data available
to lower priority tasks after the context switch.Â* That is the gist.


As I understand, the CPU fetched prived data "under the hood" even before
the processor has decided that it was prived data. When the user process
get an "slap on the hand", the tracks was already in the cache.

There was never any "context switch" involved at all, it was way below
such constructs. Everything was done from user level "under the radar"
from the point of view of the any OS (or the protection facilities in
the CPU itself, it also seems).

I didn't mean OS level CS but privilege level switching. Sorry for the
ambiguity.


And it never made any priviledge data avalable at all. It used the prived
data (byte) that was pre-fetched as an index into an array in user memory
and could later identify what element of the user data that was touched.

Clever...

Interesting.


--
“When it is all said and done, there are approximately 94 million
full-time workers in private industry paying taxes to support 102
million non-workers and 21 million government workers.
In what world does this represent a strong job market?�
..Jim Quinn

DaveFroble wrote:

Speculative execution is part of the HW, not software. It appears the HW
doesn't follow it's own rules. Or, perhaps I don't actually understand the problem?

In the case of one of the two problems, that is definitely the case and it
is very obviously a hardware problem.

In the case of the other problem, it's even worse than that. It's not just
a hardware implementation problem but a conceptualization problem. They
didn't just implement a thing wrong in hardware, they implemented the wrong
thing. And because it's in hardware it's going to be hard to fix.

Back in the seventies, stuff like this was being discovered all the time and
there were processor ECOs and microcode patches to deal with them. I
remember running a Pr1me machine for months with some kind of grant card in
place of the I-cache card because of a consistency bug. But we thought all
that stuff had been dealt with and that memory protection was a solved problem.
Turns out, maybe not.

Actually, it's kind of cool if you think about it that way.
Maybe someday we'll get capability architectures and never have to worry about
this stuff again.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2018-01-06 17:11, Alan Browne wrote:
On 2018-01-06 11:06, Jan-Erik Soderholm wrote:
Den 2018-01-06 kl. 16:27, skrev Alan Browne:
On 2018-01-05 16:00, DaveFroble wrote:
Alan Browne wrote:
On 2018-01-05 09:15, DaveFroble wrote:
Jan-Erik Soderholm wrote:

Becuse the designers, for performance reasons, has mapped kernel
memory
into the user process address space and relies on the OS to check
protection before any kernel memory (or code) is accessed.

The issue with the current issues is that the hardware (the CPU)
does
these accesses in hardware "under the hood" without control by
the OS.

If you map your kernel memory in another way that uses the hardware
protection facilities, you are (as I understand) safe, at the cost
of worse performance to switch between user and kernel mode.



As I wrote, someone dropped the ball on this one.

Speculative execution is part of the HW, not software.Â* It appears
the HW doesn't follow it's own rules.Â* Or, perhaps I don't
actually understand the problem?

At least as well as I do.Â* These are very complex mechanisms and
complexity is usually where you're most likely to get problems.

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.


There seems a whole bunch of us "speculating" about things we
probably don't know enough about.

I am very certain that they either did not design the testing
correctly or didn't test per the test plan correctly.Â* Or a bad
scenario: they saw it and carpeted it.


:-)

It seems to me that before memory is fetched into cache, the CPU
should be determining whether it should indeed be fetching that
memory.Â* Yeah,

The CPU memory controller is (usually) the arbiter of whether a fetch
is "legal" in the privilege scheme - so if something is allowed to be
fetched, then it is fetched.Â* So (hierarchically) the fetch goes to
the decoding pipeline(s) -and- is simultaneously copied to the cache.
At that point the MC has "allowed" the fetch.Â* Writes to memory are
also written to cache. The issue seems to be that post fetch from
Kernel assigned memory, the cache makes some privileged data
available to lower priority tasks after the context switch.Â* That is
the gist.


As I understand, the CPU fetched prived data "under the hood" even before
the processor has decided that it was prived data. When the user process
get an "slap on the hand", the tracks was already in the cache.

There was never any "context switch" involved at all, it was way below
such constructs. Everything was done from user level "under the radar"
from the point of view of the any OS (or the protection facilities in
the CPU itself, it also seems).

I didn't mean OS level CS but privilege level switching.Â* Sorry for the
ambiguity.

Nothing like that either. You just speculatively read data that is in
theYOUR address space, but protected from user access. The speculative
execution fetches the data, even though you are not allowed to read it.
No CS, not even any privilege level change happened.

You just make a speculative execution of an instruction that would fail
because you do not have the right to access the memory, but since it is
speculative, the trap never happens, as it later turns out that the
speculation was wrong. However, the data was still read, since the
speculative execution itself actually bypass the protection. The
protection trap will only hit you if the instruction is decided that it
actually would happen.
But unfortunately, the cache will still hold the read data that you were
not supposed to see.
And then they figured out a clever way of mining the contents of the cache.

One could argue that the cache should be invalidated in such a scenario,
but that is not happening either.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Doomsdrzej wrote:

I want power in my vehicle as well as the ability to drive as far as I
want to and that is something electric cars will never allow for.

You might want to try the Tesla. Range isn't there yet, but it's got more
low end torque than most V-8s, and it handles decently. Range is actually
better than some of those V-8s too, though of course it takes longer to fill
which is a problem.

It's getting there. What is cool about the electric car from both a
performance and conservation standard is that you're not paying a huge
overhead running with low power most of the time. With the gasoline engine,
you have to size the engine for peak power that you're only using very
occasionally, and you pay an efficiency penalty at low power. With the
electric motor you use only what you need; you get crazy high peak power
and good efficiency in cruise at the same time.

I'm not ready to buy an electric car yet, but I wouldn't discount them if
I were you. The Tesla is way too expensive for what it is, but that will
change given time.

And I might add, given that this is a computer architecture group, that
what made these cars possible was high density battery technology, and
what made that possible was smart charging. The lithium chemistry was
known for many years but it takes a lot of charge control technology to
keep them from destroying themselves. It's not something you can do with
an 8051 anymore. CPU makes it possible.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

chrisv wrote:
Doomsdrzej wrote:

The Earth always balances itself out and
there are thousands of years of data showing this. Some periods are
cold; some periods are warm. In the end, there is a balance regardless
of what its living creatures do.

What the right-wing propagandists always "forget" is that, while there
are compensating mechanisms that tend to bring the climate back to an
equilibrium, the forces are gentle, and they work on the time-scale of
millennia. They cannot cope with a violent change in conditions
occurring over a short period of time, as in the last 100 years.

Oh, they certainly can. The problem is that the coping may involve things
that are very, very unpleasant to human beings. In the end everything will
come out okay with the climate, yes. The question is whether it will come
out okay with people or not.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

DaveFroble wrote:

I wonder whether VAX would have these problems?

Maybe, the problem is that there were several rather different cache
management schemes involved. The 11/730 had hardly any cache at all and
was practically synchronous. The uVax series had multilevel caches and
all kinds of cache consistency logic. There's an article in the
DECNical Journal from around 1988 or so describing the evolution of the
cache management.

Remember the vax architecture also has more than two rings, which forces
a certain view of the situation.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article , Scott Dorsey
wrote:


I want power in my vehicle as well as the ability to drive as far as I
want to and that is something electric cars will never allow for.

You might want to try the Tesla. Range isn't there yet, but it's got more
low end torque than most V-8s, and it handles decently. Range is actually
better than some of those V-8s too, though of course it takes longer to fill
which is a problem.

the vast majority of trips are under 50 miles, so range is not even
remotely a problem. plus, the batteries will be full every morning. you
can't refuel a gas powered vehicle while parked in your garage.

range is only a problem for long road trips, and in those cases, rent a
vehicle. eventually, that won't be a problem, as more charging stations
are built.

Alan Browne wrote:
On 2018-01-05 18:01, Pabst Blue Ribbon wrote:
Alan Browne wrote:

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.

I doubt it. Yes, it's assumption but I think Intel was aware and gave
OK to
flawed design because of performance/cost.

Possible, but I'd discount a deliberate pass. FDIV was very costly to
intel - this could be much more costly if the class action suits start
flying due to increased computing costs and so on.


If FDIV is what I remember as the problem in the 386 CPU, then it wasn't so much
that the problem was costly, it was more that Intel's reaction to the problem
was costly. They tried to say the problem affected few users and didn't want to
replace defective CPUs. Well, people aren't that stupid. They saw through
Intel's attitude. That's what hurt Intel the most.

Before that, when an error in the VAX 750 FP unit was discovered, DEC came up
with a fix and implemented it. DEC field service got a bit busy. DEC's
attitude was much different than Intel's, and they were rewarded by customers
acknowledging their commitment to excellence.

Now I may be an aberration, (actually I most likely am), but I still distrust
Intel, and use AMD whenever possible. Not that I feel AMD could stand up to the
integrity DEC showed int he past, few could.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail:
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Op 4/01/2018 om 18:44 schreef Roger Blake:
On 2018-01-04, chrisv wrote:
This is ugly. Think of the large computing centers, for example
Google's data centers. Suddenly, they will need significantly more
CPU time, and thus electricity (and thus carbon), to get the job done?

Carbon is not a pollutant


I wonder what's making you such a expert...
--
Carpe Diem

"Make things as simple as possible,
but not simpler (Albert Einstein).

Pabst Blue Ribbon wrote:
DaveFroble wrote:
Pabst Blue Ribbon wrote:
Jan-Erik Soderholm wrote:
Den 2018-01-06 kl. 00:01, skrev Pabst Blue Ribbon:

[Why quote 100s of lines?]
My newsreader is not that great with editing.

I wonder if Intel will be sued because of that.
https://www.theregister.co.uk/2018/0...cpu_flaw_sued/

"Here come the lawyers! Intel slapped with three Meltdown bug lawsuits!"
Thank you. Just like I expected.
Well, the lawyers will try anything. Doesn't mean they have a case. Lots of
examples.

Make liquor, somebody gets hurt ....

Make guns, somebody gets shot ....

Make cars, somebody gets hurt ....

Make cars, cars do not perform as advertised or not as safe as expected,
have to do a recall.



Unless you are Ford with the Pinto fuel tank problem.

The person who came up with the idea that it would be cheaper to pay off the law
suits than to do a recall and fix the problem is most likely alive and well in
too many companies. As soon as you put money ahead of people, there is a
problem. We hang murderers, why not those who are worse?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail:
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 1/5/2018 10:46 AM, Doomsdrzej wrote:
On Fri, 5 Jan 2018 10:43:48 -0500, Alan Browne
wrote:

On 2018-01-05 10:13, Doomsdrzej wrote:
On Fri, 05 Jan 2018 10:04:06 +0100, Peter Köhlmann
wrote:

Roger Blake wrote:

On 2018-01-04, chrisv wrote:
Might I say that was an awesome post, sir.

His post was sheer idiocy. CO2 is not a pollutant - period.

Human caused "climate change/global warming" is junk science at
its worst.

Idiot

Another thought-provoking and irrefutable post by Mainz's greatest
export, Peter the Klöwn.

A funny thing about your sort is you believe that putting down others
makes your point valid and that resonates in your little echo chambers
as some sort of truth.

Says the hypocrite who just defended someone calling another poster an
"idiot."

While there is wisdom in crowds...

... there is none in your posts.

*plonk*


Like the rest of the science deniers, go ahead and stick your head back
in the sand.

On 2018-01-06 12:01, DaveFroble wrote:
Alan Browne wrote:
On 2018-01-05 18:01, Pabst Blue Ribbon wrote:
Alan Browne wrote:

In this case the h/w implementation didn't reflect the design goal.

This means intel had very poor design review and abysmal testing of
security features.

I doubt it. Yes, it's assumption but I think Intel was aware and gave
OK to
flawed design because of performance/cost.

Possible, but I'd discount a deliberate pass.Â* FDIV was very costly to
intel - this could be much more costly if the class action suits start
flying due to increased computing costs and so on.


If FDIV is what I remember as the problem in the 386 CPU, then it wasn't
so much that the problem was costly, it was more that Intel's reaction
to the problem was costly.Â* They tried to say the problem affected few
users and didn't want to replace defective CPUs.Â* Well, people aren't
that stupid.Â* They saw through Intel's attitude.Â* That's what hurt Intel
the most.

Nearly $500M to resolve. That was real money back then. (Nearly $1B in
today's terms).

In recent news: appears intel's CEO recently sold half of his stock ...

Since this has all broken out, intel stock has fallen and AMD's has
risen ... no surprise.

Yep, it's not worth it.

Before that, when an error in the VAX 750 FP unit was discovered, DEC
came up with a fix and implemented it.Â* DEC field service got a bit
busy.Â* DEC's attitude was much different than Intel's, and they were
rewarded by customers acknowledging their commitment to excellence.

Now I may be an aberration, (actually I most likely am), but I still
distrust Intel, and use AMD whenever possible.Â* Not that I feel AMD
could stand up to the integrity DEC showed int he past, few could.

I've had at least one AMD machine and don't recall any issues. But that
was so Windows ago... But I don't make buy decisions based on
components either. (Full disclosu moving to Mac was facilitated by
them moving to intel so I could (and still do) run legacy code in
virtualization). Other than that I don't care. I assume Macs will
switch to ARM in the next few years.

--
“When it is all said and done, there are approximately 94 million
full-time workers in private industry paying taxes to support 102
million non-workers and 21 million government workers.
In what world does this represent a strong job market?�
..Jim Quinn

On 01/06/2018 12:13 PM, DaveFroble wrote:
Pabst Blue Ribbon wrote:
DaveFroble wrote:
Pabst Blue Ribbon wrote:
Jan-Erik Soderholm wrote:
Den 2018-01-06 kl. 00:01, skrev Pabst Blue Ribbon:

[Why quote 100s of lines?]
My newsreader is not that great with editing.

I wonder if Intel will be sued because of that.
https://www.theregister.co.uk/2018/0...cpu_flaw_sued/

"Here come the lawyers! Intel slapped with three Meltdown bug
lawsuits!"
Thank you. Just like I expected.
Well, the lawyers will try anything.Â* Doesn't mean they have a case.
Lots of examples.

Make liquor, somebody gets hurt ....

Make guns, somebody gets shot ....

Make cars, somebody gets hurt ....

Make cars, cars do not perform as advertised or not as safe as expected,
have to do a recall.



Unless you are Ford with the Pinto fuel tank problem.

The person who came up with the idea that it would be cheaper to pay off
the law suits than to do a recall and fix the problem is most likely
alive and well in too many companies.Â* As soon as you put money ahead of
people, there is a problem.Â* We hang murderers, why not those who are
worse?


Dave, you live in PA. PA does not execute anyone. They
punish them by making the taxpayers support them for the
rest of their lives to include things like TV, gym facilities,
college degrees, full medical coverage. And many more things
the average taxpayer can't afford.

bill