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 |
#46
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
On Fri, 05 Jan 2018 17:13:12 +0100, Peter Köhlmann
wrote: Doomsdrzej wrote: On Fri, 5 Jan 2018 11:32:52 +1300, Your Name wrote: On 2018-01-04 15:28:17 +0000, chrisv said: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? It aint just Intel either. The three different CPU issues affect chips from Intel, AMD, and ARM (no mention anywhere of PowerPC or Apple's own A-series), and affect virtually all devices sold in the last 15 years - computers, tablets, smartphones, etc.! That's gonna be one heck of a clean up bill! :-( The _only_ processors which will suffer a performance slowdown as a result of these problems are Intel ones. Spectre affects all chips and the fix does not affect performance. Meltdown affects processors built since 1995 by *Intel* and the fix will slow them down up to around 65%. Bull****. I tested my system with Geekbench4 before and after the patch. The single-test was slowed by around 1%, the multi-test by somewhat less than 2%. This does not involve lots of I/O, but it indicates that processor speed is very little affected. The measured values are barely higher than differences due to background tasks in the single test. Both values are not at all "being able to be felt" by the user. Notice that my machine constantly runs 3 diffferent databases too Either post a video of you doing the test of post some data proving what you claim. As we both know, just about _nothing_ you write has even a shred of truth or objectivity to it and there is no reason to believe a word of what you write. We both know that you won't though because you and I know that you're a liar. Besides, what I wrote up there is based on actual benchmarks as well as articles, not the word of some unemployed Klöwn from Mainz. |
Ads |
#47
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
On 2018-01-05 13:44, Doomsdrzej wrote:
On Fri, 5 Jan 2018 10:29:31 -0500, Alan Browne wrote: On 2018-01-05 10:09, Doomsdrzej wrote: The _only_ processors which will suffer a performance slowdown as a result of these problems are Intel ones. Spectre affects all chips and the fix does not affect performance. Meltdown affects processors built since 1995 by *Intel* and the fix will slow them down up to around 65%. https://support.apple.com/en-us/HT208394 0 slowdown for the Meltdown fix. 2.5% slowdown for the Spectre fix in one of three benchmarks. Belying what you say above. So your "credentials" are decaying quick. [3rd party benchmarks] Not clear if the fix will be "improved" in 10.13.3 (the next update) and whether that will impact CPU. Since I don't want to just take Apple's word for it or that of one of its zealots, I prefer to look at actual benchmarks. I don't believe Windows zealots either and want raw data. Here is Phoronix, a Linux site, showing the performance impact of the patch: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2 Now, you can be classy and apologize or continue being a dick. I imagine that you'll choose the latter. Since I only referred to Apple, and made clear that they (allegedly) have more to come (in 10.13.3) I have no obligation to apologize. Likewise, Apple, for all of their opaqueness, are not prone to lying about such things. And finally of course, the benchmarks you refer to have absolutely nothing to do with Mac OS, so in the dick quotient department I'm afraid you're way out in front. Mac OS is already a slow piece of poop that caters to the dumbest elements of society so I doubt that any of the retards using it would notice a slowdown of their slow as molasses operating system no matter how significant it was. That's just bad math. If something is slow, then a percentage slowdown is much more noticeable than the same percentage slowdown on a faster machine. What in particular is slower about Mac OS? Filesystem, application load time, game performance, OpenGL in general, etc.. Here's a link on game performance from 2015. There is no reason to believe that things are any better today. https://hooktube.com/watch?v=hRfqNuyyPvQ Some irrelevant difference in gaming. The rest of your claims are BS. Of course there are all sorts of things that account for the difference: 1. Real time apps developed and optimized for one platform don't necessarily port well to another OS. Since I've ported a lot of code (much of it "real time" across OS', I guess I'd know that in painful detail: accept the lower performance or spend a lot of re-write and testing time). 2. MS has in the past recognized the value of the gaming market and has optimized parts of the OS for that market. Apple has not made that a priority which is why it does better than Windows in the markets where it has focused (graphic arts, video, photo, creatives, scientific and to a lesser degree engineering, etc.). No surprise that you excel where you work the most and don't excel where you don't work often. I'd use a metaphor like McGregor v. Mayweather perhaps. Both excellent fighters but it was Mayweather's house. 3. As the commenter says at the start of that video, Mac gamers are a small slice of the gaming market. So game makers are not going to spend a lot of time optimizing for that market. Couple to 1 and 2 above. 4. Mac users are from higher educational and socio-economic strata and that demographic doesn't exactly go for "computer gaming" as much as the lower strata. They much prefer golf, skiing, horseback riding, perhaps polo, and certainly scuba diving and yachting. The more intrepid go for climbing. All of these are expensive sports and quite healthy too, barring accidents. BTW, Mac OS is generally used by people with higher educational achievement as well as higher income brackets. But then ... What an irrelevant thing to mention. Be quiet. Truth being inconvenient usually results in your sort of blather. Amusing. Sort of like watching lower middle class Americans bash the Wal*Mart doors on Black Friday. But frankly we're getting bored with that. Can you invent something new? -- “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 |
#48
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
On 2018-01-05 13:33, mechanic wrote:
On Fri, 5 Jan 2018 10:29:31 -0500, Alan Browne wrote: BTW, Mac OS is generally used by people with higher educational achievement as well as higher income brackets. But then ... Pity the only available vbox for macOS has no sound. If you mean virtualization there are commercial products for Mac OS that support sound. VMWare Fusion (which I use for Windows and Linux) and Parallels. If you mean the product VBox, I don't know. But given that it's "free" you do get what you pay for, usually. -- “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 |
#49
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
"Roger Blake" wrote
| His post was sheer idiocy. CO2 is not a pollutant - period. | If you think he's wrong then why do you systematically misinterpret his statements? Are you afraid to address the points rationally and analytically? No one said carbon was a pollutant. No one said CO2 was a pollutant. You disagree stridently but don't have enough confidence in your own position to rebut with anything but nonsense? Or do you really believe that someone is claiming CO2 to be a pollutant? (Maybe I can help you to win this argument. Spring this one on him: Thanks to Ronald Reagan we all know that the real pollutant is trees. That statement is so smart that he won't know how to defend against it. The loss of performance could significantly increase the cost of operations for large computing centers. Look for the cost of online services to rise. Maybe, but a lot of them are free/ad-supported and the commercial ones have to deal with competition. The possibility that they might have to buy additional hardware may not be a big factor. |
#50
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
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. :-) 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, sounds simple, but I'm betting it isn't. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 |
#51
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
Bill Gunshannon wrote:
On 01/05/2018 08:50 AM, Alan Browne wrote: On 2018-01-04 15:43, DaveFroble wrote: chrisv wrote: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? And once all the spanners are tossed into the works, which will slow things down, what happens when new CPUs without the issues are available? Will computers forever be artificially slowed down? A whole bunch of someones has seriously dropped the ball on this. Protected memory should be just that, protected, with no way to avoid the protection. I presume it's an implementation flaw, not a principle-of-design flaw. So once addressed, it should result in both proper memory protection and increased performance in future cores. Alas (per the article) this can't be addressed with a microcode patch. Sounds more like a "principle-of-design" flaw to me. Hard to believe all those different companies all made the same mistake building on a sound design. bill I wonder whether VAX would have these problems? :-) -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 |
#52
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
Doomsdrzej wrote:
On Fri, 5 Jan 2018 03:36:34 -0000 (UTC), 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. Even Reid Bryson, the scientist who was the father of modern climate science, stated that it is "a bunch of hooey." As I said, I absolutely refuse to reduce my own carbon emissions and in fact continue to see ways to increase them. (Do you dumbass hippies really believe that your stoopid windmills are solar panels are capable of keeping people warm and alive in the deep freeze that so much of the U.S. is currently experiencing?) I'm going to hate myself for doing this ... I _refuse_ to buy an electic car which has horrible range, little storage and looks absolutely awful in the hope that mining lithium to power them somehow causes less pollution than driving a regular, gas-burning car. Range, storage, and looks have nothing to do with electric vs gasoline. If some goofy designer feels he has to make an electric car look like a golf cart, that's his decision, not reality. As for pollution, it depends on how the electricity is produced. How is mining any worse than drilling for oil? 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. An electric vehicle can have plenty of power. Just as in a gasoline fueled car, it depends on how much energy one wishes to expend. As far as distance, you can only go as far as the next gas station. Empty tank, or dead battery, both leave you walking. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 |
#53
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
On 2018-01-05 15:09:49 +0000, Doomsdrzej said:
On Fri, 5 Jan 2018 11:32:52 +1300, Your Name wrote: On 2018-01-04 15:28:17 +0000, chrisv said: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? It aint just Intel either. The three different CPU issues affect chips from Intel, AMD, and ARM (no mention anywhere of PowerPC or Apple's own A-series), and affect virtually all devices sold in the last 15 years - computers, tablets, smartphones, etc.! That's gonna be one heck of a clean up bill! :-( The _only_ processors which will suffer a performance slowdown as a result of these problems are Intel ones. Spectre affects all chips and the fix does not affect performance. Meltdown affects processors built since 1995 by *Intel* and the fix will slow them down up to around 65%. There's actually THREE issues (at least), despite the fact that the media is over-hyping just those two. |
#54
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
On 01/05/2018 04:04 PM, DaveFroble wrote:
Bill Gunshannon wrote: On 01/05/2018 08:50 AM, Alan Browne wrote: On 2018-01-04 15:43, DaveFroble wrote: chrisv wrote: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? And once all the spanners are tossed into the works, which will slow things down, what happens when new CPUs without the issues are available?Â* Will computers forever be artificially slowed down? A whole bunch of someones has seriously dropped the ball on this. Protected memory should be just that, protected, with no way to avoid the protection. I presume it's an implementation flaw, not a principle-of-design flaw. So once addressed, it should result in both proper memory protection and increased performance in future cores.Â* Alas (per the article) this can't be addressed with a microcode patch. Sounds more like a "principle-of-design" flaw to me.Â* Hard to believe all those different companies all made the same mistake building on a sound design. bill I wonder whether VAX would have these problems? :-) VAX didn't have the capabilities that lead to this problem. I think Alpha does, however. bill |
#55
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign
"Tim Streater" 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 ... | | This in itself is meaningless. Nature itself is never in balance. | One could say that Nature is balance. Life only exists as a constant rebalancing to maintain a kind of stasis. But I know what you mean. There's only such a thing as equilibrium from an anthropocentric point of view. What the right-wingers seem to miss is that while the Earth will do fine, whether it's iced over or steaming, humanity may not. |
#56
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
Bill Gunshannon wrote:
On 01/05/2018 04:04 PM, DaveFroble wrote: Bill Gunshannon wrote: On 01/05/2018 08:50 AM, Alan Browne wrote: On 2018-01-04 15:43, DaveFroble wrote: chrisv wrote: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? And once all the spanners are tossed into the works, which will slow things down, what happens when new CPUs without the issues are available? Will computers forever be artificially slowed down? A whole bunch of someones has seriously dropped the ball on this. Protected memory should be just that, protected, with no way to avoid the protection. I presume it's an implementation flaw, not a principle-of-design flaw. So once addressed, it should result in both proper memory protection and increased performance in future cores. Alas (per the article) this can't be addressed with a microcode patch. Sounds more like a "principle-of-design" flaw to me. Hard to believe all those different companies all made the same mistake building on a sound design. bill I wonder whether VAX would have these problems? :-) VAX didn't have the capabilities that lead to this problem. I think Alpha does, however. bill :-) Yeah, I know that. No predictive speculation in VAX. Now, as for Alpha, yes, OoO and such, but, the question would be, does it allow "illegal" access to memory? If Alpha does not allow loading memory it should not into cache, then perhaps not a problem. -- David Froble Tel: 724-529-0450 Dave Froble Enterprises, Inc. E-Mail: DFE Ultralights, Inc. 170 Grimplin Road Vanderbilt, PA 15486 |
#57
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processor design flawforces Linux, Windows redesign
Den 2018-01-05 kl. 23:41, skrev DaveFroble:
Bill Gunshannon wrote: On 01/05/2018 04:04 PM, DaveFroble wrote: Bill Gunshannon wrote: On 01/05/2018 08:50 AM, Alan Browne wrote: On 2018-01-04 15:43, DaveFroble wrote: chrisv wrote: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? And once all the spanners are tossed into the works, which will slow things down, what happens when new CPUs without the issues are available?Â* Will computers forever be artificially slowed down? A whole bunch of someones has seriously dropped the ball on this. Protected memory should be just that, protected, with no way to avoid the protection. I presume it's an implementation flaw, not a principle-of-design flaw. So once addressed, it should result in both proper memory protection and increased performance in future cores.Â* Alas (per the article) this can't be addressed with a microcode patch. Sounds more like a "principle-of-design" flaw to me.Â* Hard to believe all those different companies all made the same mistake building on a sound design. bill I wonder whether VAX would have these problems? :-) VAX didn't have the capabilities that lead to this problem. I think Alpha does, however. bill :-) Yeah, I know that.Â* No predictive speculation in VAX. Now, as for Alpha, yes, OoO and such, but, the question would be, does it allow "illegal" access to memory?... The problem with the current issue seems to be that the speculative pre-fetch is done on a lower level then the page protection checks. When the page-protection kicks in, the fetch has already been done. I have no idea how that is designed on the Alpha. If Alpha does not allow loading memory it should not into cache, then perhaps not a problem. |
#58
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processordesign flaw forces Linux, Windows redesign
Designed By India H1B Engineers wrote:
Performance hits loom, other OSes need fixes Updated A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug. Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December. Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary. The Register ? @TheRegister PostgreSQL SELECT 1 with the KPTI workaround for Intel CPU vulnerability https://www.postgresql.org/message- … Best case: 17% slowdown Worst case: 23% 3:58 PM - Jan 2, 2018 12 12 Replies 331 331 Retweets 212 212 likes Twitter Ads info and privacy Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder. Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue. However, some details of the flaw have surfaced, and so this is what we know. Impact It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas. The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka ****WIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers. Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables. Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it. These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way. The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer. Your Intel-powered machine will run slower as a result. How can this security hole be abused? At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs. At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data. Specifically, in terms of the best-case scenario, it is possible the bug could be abused to defeat KASLR: kernel address space layout randomization. This is a defense mechanism used by various operating systems to place components of the kernel in randomized locations in virtual memory. This mechanism can thwart attempts to abuse other bugs within the kernel: typically, exploit code – particularly return-oriented programming exploits – relies on reusing computer instructions in known locations in memory. If you randomize the placing of the kernel's code in memory, exploits can't find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching. However, it may be that the vulnerability in Intel's chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is: AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to obey, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it. It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs. That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good. The specifics of the vulnerability have yet to be confirmed, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it's more serious than a KASLR bypass. Also, the updates to separate kernel and user address spaces on Linux are based on a set of fixes dubbed the KAISER patches, which were created by eggheads at Graz University of Technology in Austria. These boffins discovered [PDF] it was possible to defeat KASLR by extracting memory layout information from the kernel in a side-channel attack on the CPU's virtual memory system. The team proposed splitting kernel and user spaces to prevent this information leak, and their research sparked this round of patching. Their work was reviewed by Anders Fogh, who wrote this interesting blog post in July. That article described his attempts to read kernel memory from user mode by abusing speculative execution. Although Fogh was unable to come up with any working proof-of-concept code, he noted: My results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode. It appears the KAISER work is related to Fogh's research, and as well as developing a practical means to break KASLR by abusing virtual memory layouts, the team may have somehow proved Fogh right – that speculative execution on Intel x86 chips can be exploited to access kernel memory. Shared systems The bug will impact big-name cloud computing environments including Amazon EC2, Microsoft Azure, and Google Compute Engine, said a software developer blogging as Python Sweetness in this heavily shared and tweeted article on Monday: There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads. There are hints the attack impacts common virtualisation environments including Amazon EC2 and Google Compute Engine... Microsoft's Azure cloud – which runs a lot of Linux as well as Windows – will undergo maintenance and reboots on January 10, presumably to roll out the above fixes. Amazon Web Services also warned customers via email to expect a major security update to land on Friday this week, without going into details. There were rumors of a severe hypervisor bug – possibly in Xen – doing the rounds at the end of 2017. It may be that this hardware flaw is that rumored bug: that hypervisors can be attacked via this kernel memory access cockup, and thus need to be patched, forcing a mass restart of guest virtual machines. A spokesperson for Intel was not available for comment. ® Updated to add The Intel processor flaw is real. A PhD student at the systems and network security group at Vrije Universiteit Amsterdam has developed a proof-of-concept program that exploits the Chipzilla flaw to read kernel memory from user mode: View image on Twitter View image on Twitter brainsmoke @brainsmoke Bingo! #kpti #intelbug 6:28 AM - Jan 3, 2018 58 58 Replies 1,687 1,687 Retweets 2,362 2,362 likes Twitter Ads info and privacy The Register has also seen proof-of-concept exploit code that leaks a tiny amount of kernel memory to user processes. Finally, macOS has been patched to counter the chip design blunder since version 10.13.2, according to operating system kernel expert Alex Ionescu. And it appears 64-bit ARM Linux kernels will also get a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR. We'll be following up this week. https://www.theregister.co.uk/2018/0...u_design_flaw/ -- Windows 2000 Pro RC2 on Alpha. I wonder if Intel will be sued because of that. I also assume it's impossible Intel high-ranked engineers were not aware of the issue; however, even if this is the case, it probably would be hard to prove it in court. |
#59
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processordesign flaw forces Linux, Windows redesign
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. I doubt it. Yes, it's assumption but I think Intel was aware and gave OK to flawed design because of performance/cost. |
#60
|
|||
|
|||
Intel junk...Kernel-memory-leaking Intel processordesign flaw forces Linux, Windows redesign
Peter Köhlmann wrote:
Doomsdrzej wrote: On Fri, 5 Jan 2018 11:32:52 +1300, Your Name wrote: On 2018-01-04 15:28:17 +0000, chrisv said: Designed By India H1B Engineers wrote: Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. 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? It aint just Intel either. The three different CPU issues affect chips from Intel, AMD, and ARM (no mention anywhere of PowerPC or Apple's own A-series), and affect virtually all devices sold in the last 15 years - computers, tablets, smartphones, etc.! That's gonna be one heck of a clean up bill! :-( The _only_ processors which will suffer a performance slowdown as a result of these problems are Intel ones. Spectre affects all chips and the fix does not affect performance. Meltdown affects processors built since 1995 by *Intel* and the fix will slow them down up to around 65%. Bull****. I tested my system with Geekbench4 before and after the patch. The single-test was slowed by around 1%, the multi-test by somewhat less than 2%. This does not involve lots of I/O, but it indicates that processor speed is very little affected. The measured values are barely higher than differences due to background tasks in the single test. Both values are not at all "being able to be felt" by the user. I disagree. Calculate 2% of your income. Is it "very little" money? If you have to give 2% of your income to, let's say, me - will you be able to feel it? |
Thread Tools | |
Display Modes | Rate This Thread |
|
|