I'm no fan of Intel but I can't help but see Meltdown as at least partly the fault of OS vendors. They decided to keep kernel and user memory in the same address space for performance despite known problems with branch prediction and despite KPTI being an option.
I doubt Intel ever claimed prediction could not be detected nor forced kernel devs not to use KPTI. Usually when a vulnerability is found in a software architecture you blame the software.
Intel did not introduce PCID until recently so I can hardly fault the OS vendors about something which Intel was apparently aware of without notifying them.
The bug I can understand. I am more upset about Intel's disingenuous PR statements which conflate different exploits making it seem that their main competitor is no better.
For once I am happy about Intel's excessive market segmentation; it convinced me to go with AMD after the Pentium 4.
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
The timeline fits with things Bob Colwell said about changes for the worse in Intel's management just before he left Intel.
Speculative execution across ring changes is the root cause of this. AMD doesn't do this because Intel patented it, told AMD, and didn't include it in their cross-licensing agreement.
AMD does not do this because they check TLB permissions on speculative loads instead of waiting until instruction retirement. The speculation still happens up until the load.
The MMU protection isn't bypassed, because the instructions that would be bypassing the MMU protection are cancelled.
And AMD just never speculates the instructions which would cause a protection fault until the branch is resolved.
Thinking about it now, this *is* slower by a tiny bit but fixing it with address isolation is massively slower.
You can bet that AMD was just waiting for the patent to expire before doing it, because without it you have to wait until all branches up to the system call have been retired before you can perform the transition.
I read that AMD has a patent for checking the permissions during the speculative load but I do not know why this would not be part of their cross licensing agreement with Intel. Apparently this goes back to the Opteron.
And when Intel did this, everyone was happy that the cost of system calls went down. Now everyone is saying that they secretly knew that it was a security issue and only an idiot would have implemented it.
Checking TLB permissions during speculation as AMD does has nothing to do with system calls.
The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.
Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)
AMD checks permissions on every TLB access while Intel delays the permission check (or result) until instruction retirement which is when faults are acted on. It does not make any sense to act on a fault on a speculated branch until the branch is resolved.
Since AMD never does the speculated load, there is no data for the speculated branch to use making them immune to Meltdown. The speculated instructions past the load never get executed.
I do not understand why Intel's method would be any faster. Reloading TLBs and doing housekeeping for privilege changes are a separate issue.
Note that AMD is far from innocent in this respect - just remember how they skilfully downplayed their infamous TLB errata.
I might suspect that their Phenom TLB problem had a connection with not speculating invalid loads but apparently their earlier processors did not suffer from this problem either.
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
How is that? Checking for permissions before speculation costs hardware and power but not speculating a path which is not going to be used anyway is hardly going to increase latency and saves the power which would otherwise be used and the cost of any memory transactions.
System calls involve a lot of microcode and other functions so it is not surprising they have a high and different cost between processors.
64MB RAM? Eh??? Back then 64MB of RAM cost £60k. And I don't think PCs supported more than 8 or 16MB. I had 4x1MB 30pin and had 2 72pin slots free. Later added 2x2MB in 95 or thereabouts. X would fly with 8 megs. Anyway I forgot more about Linux then I know right now but I think it did run on DX (i.e. 32-bit) machines only, SX was 16-bit, right?
I had an early MIcronics 486 motherboard which had 8 30-pin SIMM sockets. I originally had 8MB but had planned to update it to 4MB SIMMs for 32MB which the motherboard was suppose to support. But when the board was designed they did not have 4MB SIMMs to test it with and as it ends up, it would not work with them even though it was suppose to.
It's actually worse than that, since Windows 8 and later require the NX bit, which came out around the same time as 64-bit, so you can't install Windows 8/10 on anything older than about 2005 or so. I don't think there are any chips that have the NX bit but lack SSE2, but plenty the other way around, like any Socket 478 P4.
I have a number of old systems now which would be fast enough for various things but Windows will no longer operate on because they lack SSE2.
What can you do with a 486 Linux system? Probably more then you think. Just not as many things at once. You can run a web server, a database probably not both at the same time. However if you maxed the RAM you could get a lot done on slow CPU. If you checked you fast Computer most of the time your CPU is idle. On a 486 you can do nearly anything you can do on any other 32bit computer.
I used a 486 as a firewall and router for a number of years. For even longer I used a Pentium 60 which was not much faster.
- encryption isn't an obligation on digital signal : in lot of countries (e.g.: in europe), DAB is broadcast the exact same way as FM - freely for anyone to catch. No subscription, DRM or whatever. And public channels (those paid by public funds, like taxes or via a separate non-government taxation system - e.g.: in CH) never air advertisement.
Unlike FM, DAB is buried under a patent pool which requires licensing.
They also seem hell bent on obsoleting it periodically so new receivers have to be purchased.
Backdoor for domestic police state? That would be China. At least the USA has structural separation between businesses (like Intel), and the government. And is a country of laws.
Do you mean like the separation between the NSA and RSA, Inc.?
Since there are zero cases where the flaw has been exploited to cause any problems, no one has suffered any economic harm. You need to have been harmed in some way to have standing to sue.
Having their CPU lose a significant amount of performance is economic harm.
All Intel CPUs with speculative execution are affected by Meltdown, and all CPUs with speculative execution, including those by AMD and ARM are vulnerable to Spectre. Intel discovering that a year before Google would be a coincidence. It is not just a bug, it is a fundamental issue in the way all modern CPUs are designed.
So why were AMD's CPUs designed in such a way as to be immune to Meltdown? Did they notice this problem years ago?
The current approach is to do any bounds checking *after* the speculative execution in the event that the branch is to be executed, which is what enables the kernel memory to be leaked to userspace programmes. The secure way of doing it would be to do the bounds checking *during* the speculative execution, just as you would with normal execution, and in the event of a page fault fall back to the non-speculative execution approach. That would still be slightly slower, but not as bad as forcing the non-speculative execution approach every time, which is what the patches have now enforced.
Since visible faults must be generated at instruction retirement, the option is not to check at the start of speculation or at retirement but to check at retirement or at both. So checking during speculation is extra work that Intel elected not to perform but as it ends up, doing so is very important to prevent side channel attacks.
I don't know. GPS was never supposed to be used for anything like this.
*Civilian* GPS was not supposed to be used like this and got limitations (speed, altitude *) to avoid being usable like this.
It has been a while since I studied them but I think the ITAR regulations only apply if the GPS receiver is exported as with cryptography. An export regulation makes a nice unambiguous jurisdictional hook. Of course as a practical matter, this applies to any mass produced implementation. If this is an issue for SpaceX, then they should have no trouble getting a licensed exception and I assume some of the ASIC manufacturers produce a custom firmware without the civilian ITAR restrictions or that SpaceX can procure a military receiver from one of the companies which make them.
Does not "corrupt, modify or delete data". Yes, nice. It can just steal your passwords and encryption keys and then use them to do that corruption, modification or deletion. A shameless lie by misdirection. Intel has no honor at all.
Or Meltdown can be used to find the protected data structures in the OS so that Rowhammer can then be used to escalate privilege level.
And how would pollution be accounted for, particularly when in most environments it actually takes time for pollutants to build up to a level where they start a problem?
To my mind, a keen capitalist in such a "free market" would busy himself maximizing profits by ignoring pollution, and then walk away once the extent of the damage he had done became evident.
Without without a Pigovian tax, they do not ignore the pollution. Instead they buy the government making it a form of rent seeking. And the government is happy to go along with it.
I'm much more surprised this can't be fixed in microcode, the entire CPU is run by its own "OS" since Pentium 1 the Intel CISC is just a translation to RISC so you should be able to patch it out. If not, it's not like the Pentium F00F bug anymore, these days we're using millions of CPU's per year, recalling even the last 5 years worth is suicide for Intel.
I got the feeling reading technical details that it can be fixed in microcode by disabling speculative execution which entails an even larger performance hit.
Slashdot Mirror
I'm no fan of Intel but I can't help but see Meltdown as at least partly the fault of OS vendors. They decided to keep kernel and user memory in the same address space for performance despite known problems with branch prediction and despite KPTI being an option.
I doubt Intel ever claimed prediction could not be detected nor forced kernel devs not to use KPTI. Usually when a vulnerability is found in a software architecture you blame the software.
Intel did not introduce PCID until recently so I can hardly fault the OS vendors about something which Intel was apparently aware of without notifying them.
The bug I can understand. I am more upset about Intel's disingenuous PR statements which conflate different exploits making it seem that their main competitor is no better.
For once I am happy about Intel's excessive market segmentation; it convinced me to go with AMD after the Pentium 4.
That meeting there in late 2013 signalled a sea change at Intel to many of us who were there.
Well maybe it was, but these problems predate 2013. Guess the "validation" that was happening in the 18 years between 1995 and 2013 didn't amount to much.
The timeline fits with things Bob Colwell said about changes for the worse in Intel's management just before he left Intel.
Speculative execution across ring changes is the root cause of this. AMD doesn't do this because Intel patented it, told AMD, and didn't include it in their cross-licensing agreement.
AMD does not do this because they check TLB permissions on speculative loads instead of waiting until instruction retirement. The speculation still happens up until the load.
The MMU protection isn't bypassed, because the instructions that would be bypassing the MMU protection are cancelled.
And AMD just never speculates the instructions which would cause a protection fault until the branch is resolved.
Thinking about it now, this *is* slower by a tiny bit but fixing it with address isolation is massively slower.
You can bet that AMD was just waiting for the patent to expire before doing it, because without it you have to wait until all branches up to the system call have been retired before you can perform the transition.
I read that AMD has a patent for checking the permissions during the speculative load but I do not know why this would not be part of their cross licensing agreement with Intel. Apparently this goes back to the Opteron.
And when Intel did this, everyone was happy that the cost of system calls went down. Now everyone is saying that they secretly knew that it was a security issue and only an idiot would have implemented it.
Checking TLB permissions during speculation as AMD does has nothing to do with system calls.
The specific issue that Pentium line CPUs: a) do privilege check asynchronously; b) do it only for the "winning" execution branch was very well known among CPU design community.
Intel architects even bragged about that as their "innovation" in industry journals and filled a number of patents for that (this is the reason amd privilege checker runs on all branches)
AMD checks permissions on every TLB access while Intel delays the permission check (or result) until instruction retirement which is when faults are acted on. It does not make any sense to act on a fault on a speculated branch until the branch is resolved.
Since AMD never does the speculated load, there is no data for the speculated branch to use making them immune to Meltdown. The speculated instructions past the load never get executed.
I do not understand why Intel's method would be any faster. Reloading TLBs and doing housekeeping for privilege changes are a separate issue.
Note that AMD is far from innocent in this respect - just remember how they skilfully downplayed their infamous TLB errata.
I might suspect that their Phenom TLB problem had a connection with not speculating invalid loads but apparently their earlier processors did not suffer from this problem either.
Nope, AMD pays a higher penalty on system calls, though they mitigate this to some extent by having shorter and narrower pipelines.
How is that? Checking for permissions before speculation costs hardware and power but not speculating a path which is not going to be used anyway is hardly going to increase latency and saves the power which would otherwise be used and the cost of any memory transactions.
System calls involve a lot of microcode and other functions so it is not surprising they have a high and different cost between processors.
Sounds like timing is the thing that doesn't need to cross security boundaries. Timing itself can be inferred.
One of the countermeasures for sandbox environments is to lower the timing resolution but this only lowers the rate at which data can be recovered.
64MB RAM? Eh??? Back then 64MB of RAM cost £60k. And I don't think PCs supported more than 8 or 16MB. I had 4x1MB 30pin and had 2 72pin slots free. Later added 2x2MB in 95 or thereabouts. X would fly with 8 megs. Anyway I forgot more about Linux then I know right now but I think it did run on DX (i.e. 32-bit) machines only, SX was 16-bit, right?
I had an early MIcronics 486 motherboard which had 8 30-pin SIMM sockets. I originally had 8MB but had planned to update it to 4MB SIMMs for 32MB which the motherboard was suppose to support. But when the board was designed they did not have 4MB SIMMs to test it with and as it ends up, it would not work with them even though it was suppose to.
It's actually worse than that, since Windows 8 and later require the NX bit, which came out around the same time as 64-bit, so you can't install Windows 8/10 on anything older than about 2005 or so. I don't think there are any chips that have the NX bit but lack SSE2, but plenty the other way around, like any Socket 478 P4.
I have a number of old systems now which would be fast enough for various things but Windows will no longer operate on because they lack SSE2.
What can you do with a 486 Linux system? Probably more then you think. Just not as many things at once. You can run a web server, a database probably not both at the same time. However if you maxed the RAM you could get a lot done on slow CPU. If you checked you fast Computer most of the time your CPU is idle. On a 486 you can do nearly anything you can do on any other 32bit computer.
I used a 486 as a firewall and router for a number of years. For even longer I used a Pentium 60 which was not much faster.
Not to mention the amount of driver distraction it would cause. I'd expect legislation soon to take care of this.
So legislation that makes sure the legislators or their friends get a cut?
- encryption isn't an obligation on digital signal : in lot of countries (e.g.: in europe), DAB is broadcast the exact same way as FM - freely for anyone to catch. No subscription, DRM or whatever. And public channels (those paid by public funds, like taxes or via a separate non-government taxation system - e.g.: in CH) never air advertisement.
Unlike FM, DAB is buried under a patent pool which requires licensing.
They also seem hell bent on obsoleting it periodically so new receivers have to be purchased.
Backdoor for domestic police state? That would be China. At least the USA has structural separation between businesses (like Intel), and the government. And is a country of laws.
Do you mean like the separation between the NSA and RSA, Inc.?
Since there are zero cases where the flaw has been exploited to cause any problems, no one has suffered any economic harm. You need to have been harmed in some way to have standing to sue.
Having their CPU lose a significant amount of performance is economic harm.
All Intel CPUs with speculative execution are affected by Meltdown, and all CPUs with speculative execution, including those by AMD and ARM are vulnerable to Spectre. Intel discovering that a year before Google would be a coincidence. It is not just a bug, it is a fundamental issue in the way all modern CPUs are designed.
So why were AMD's CPUs designed in such a way as to be immune to Meltdown? Did they notice this problem years ago?
The current approach is to do any bounds checking *after* the speculative execution in the event that the branch is to be executed, which is what enables the kernel memory to be leaked to userspace programmes. The secure way of doing it would be to do the bounds checking *during* the speculative execution, just as you would with normal execution, and in the event of a page fault fall back to the non-speculative execution approach. That would still be slightly slower, but not as bad as forcing the non-speculative execution approach every time, which is what the patches have now enforced.
Since visible faults must be generated at instruction retirement, the option is not to check at the start of speculation or at retirement but to check at retirement or at both. So checking during speculation is extra work that Intel elected not to perform but as it ends up, doing so is very important to prevent side channel attacks.
I don't know. GPS was never supposed to be used for anything like this.
*Civilian* GPS was not supposed to be used like this and got limitations (speed, altitude *) to avoid being usable like this.
It has been a while since I studied them but I think the ITAR regulations only apply if the GPS receiver is exported as with cryptography. An export regulation makes a nice unambiguous jurisdictional hook. Of course as a practical matter, this applies to any mass produced implementation. If this is an issue for SpaceX, then they should have no trouble getting a licensed exception and I assume some of the ASIC manufacturers produce a custom firmware without the civilian ITAR restrictions or that SpaceX can procure a military receiver from one of the companies which make them.
Does not "corrupt, modify or delete data". Yes, nice. It can just steal your passwords and encryption keys and then use them to do that corruption, modification or deletion. A shameless lie by misdirection. Intel has no honor at all.
Or Meltdown can be used to find the protected data structures in the OS so that Rowhammer can then be used to escalate privilege level.
If Intel can get the same OS patches applied when an AMD processor is used, then they will keep their performance lead.
And how would pollution be accounted for, particularly when in most environments it actually takes time for pollutants to build up to a level where they start a problem?
Implement a tax based on the cost of the negative externalities.
To my mind, a keen capitalist in such a "free market" would busy himself maximizing profits by ignoring pollution, and then walk away once the extent of the damage he had done became evident.
Without without a Pigovian tax, they do not ignore the pollution. Instead they buy the government making it a form of rent seeking. And the government is happy to go along with it.
(And why are only NSA people demoralized? I'd be demoralized if I worked in _any_ branch of gov't...the way things are going.
I assume working conditions have gotten worse due to steps taken to prevent future Snowdens.
or heck if you've just got a low end laptop?
Then your low end laptop is now lower end.
I'm much more surprised this can't be fixed in microcode, the entire CPU is run by its own "OS" since Pentium 1 the Intel CISC is just a translation to RISC so you should be able to patch it out. If not, it's not like the Pentium F00F bug anymore, these days we're using millions of CPU's per year, recalling even the last 5 years worth is suicide for Intel.
I got the feeling reading technical details that it can be fixed in microcode by disabling speculative execution which entails an even larger performance hit.