If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#76
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, 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. |
Ads |
#77
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#78
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#79
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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." |
#80
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#81
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
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." |
#82
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
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." |
#83
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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." |
#84
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
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. |
#85
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#86
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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). |
#87
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#88
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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. |
#89
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
#90
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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 |
Thread Tools | |
Display Modes | Rate This Thread |
|
|