Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Thursday January 04 2018, @01:04AM   Printer-friendly
from the small-price-to-pay dept.

UPDATE 2: (martyb)

This still-developing story is full of twists and turns. It seems that Intel chips are definitely implicated (AFAICT anything post Pentium Pro). There have been various reports, and denials, that AMD and ARM are also affected. There are actually two vulnerabilities being addressed. Reports are that a local user can access arbitrary kernel memory and that, separately, a process in a VM can access contents of other virtual machines on a host system. These discoveries were embargoed for release until January 9th, but were pre-empted when The Register first leaked news of the issues.

At this time, manufacturers are scrambling to make statements on their products' susceptibility. Expect a slew of releases of urgent security fixes for a variety of OSs, as well as mandatory reboots of VMs on cloud services such as Azure and AWS. Implications are that there is going to be a performance hit on most systems, which may have cascading follow-on effects for performance-dependent activities like DB servers.

To get started, see the very readable and clearly-written article at Ars Technica: What’s behind the Intel design flaw forcing numerous patches?.

Google Security Blog: Today's CPU vulnerability: what you need to know.
Google Project Zero: Reading privileged memory with a side-channel, which goes into detail as to what problems are being addressed as well as including CVEs:

So far, there are three known variants of the issue:

  • Variant 1: bounds check bypass (CVE-2017-5753)
  • Variant 2: branch target injection (CVE-2017-5715)
  • Variant 3: rogue data cache load (CVE-2017-5754)

Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at:

During the course of our research, we developed the following proofs of concept (PoCs):

  1. A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
  2. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
  3. A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
  4. A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

According to a report in Barron's:

AMD said through a spokesperson:

There is a lot of speculation today regarding a potential security issue related to modern microprocessors and speculative execution. As we typically do when a potential security issue is identified, AMD has been working across our ecosystem to evaluate and respond to the speculative execution attack identified by a security research team to ensure our users are protected.

To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD’s architecture, we believe there is a near zero risk to AMD processors at this time. We expect the security research to be published later today and will provide further updates at that time.

UPDATE 1: (takyon)

Intel statement.

Original story follows

It appears that all modern Intel processors contain a hardware-level security flaw. Details are being suppressed while patches are developed, but it appears that a user process can put a reference to a privileged address in speculative execution, and thereby bypass privilege restrictions.

Since simply marking certain areas of the virtual memory space as privileged is insecure, operating systems will have to completely isolate their kernels, i.e., remove them from the virtual memory space of user processes. This will make context switching more expensive. Presumably, every OS call will now require swapping out the virtual memory map and flushing the page tables cache in the processor. Twice: one to go to the kernel, and once to return to the user process. This will be a significant performance hit: depending on the application, up to 30%.

This is apparently an Intel-specific bug; processors by other manufacturers are not affected. However, they may still suffer the performance hit: The changes to the OS are substantial, and it seems unlikely that OS manufacturers will, in the long-term, maintain two completely different kernel-access strategies for different processors.

Previously: Major Hardware Bug Quietly Being Patched in the Open

A bug that affects Intel processors requires Kernel Page Table Isolation in order to be mitigated:

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 FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

The fix could dramatically lower performance for some workloads:

The Python Sweetness blog, which first reported on the bug, said the vulnerability was first identified by developers working on the Linux kernel, though it also affects Windows operating systems. It added that a number of major security patches for the Linux kernel have been pushed out over the Christmas and New Year holidays, which are likely to be an attempt to fix the new bug. These kernel updates have provided a workaround that can prevent attackers from exploiting the bug, but the problem is that doing so comes at a heavy cost. In technical terms, the fix involves using Kernel Page-Table Isolation or PTI to restrict processes so they can only access their own memory area. However, PTI also affects low-level features in the hardware, resulting in a performance hit of up to 35 percent for older Intel processors.

[...] "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," the Python Sweetness blog reported Monday. "In the worst case the software fix causes huge slowdowns in typical workloads." These slowdowns were highlighted by Brad Spengler, lead developer of grsecurity, which is a set of patches for the Linux kernel which emphasize security enhancements. According to HotHardWare, Spengler said an Intel Core i7-3770S GPU will take a 34 percent performance hit, while the new Intel Core i7-6700 will run 29 percent slower.

The Linux fix can be disabled, which you will likely want to do if you use an AMD processor.

December 19, 2017: Intel's CEO Just Sold a Lot of Stock

Did Krzanich use that money to buy AMD stock?

[See also: How-To Geek, Phoronix, and Security Week. --martyb]

An Anonymous Coward contributed Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR.


Original Submission 1

Original Submission 2

Related Stories

Major Hardware Bug Quietly Being Patched in the Open 54 comments

Spotted over on HN:

The mysterious case of the Linux Page Table Isolation patches (archive)

tl;dr: there is presently an embargoed security bug impacting apparently all contemporary 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 virtualization environments including Amazon EC2 and Google Compute Engine, and additional hints the exact attack may involve a new variant of Rowhammer.

Turns out 2018 might be more interesting than first thought. So grab some popcorn and keep those systems patched!


Original Submission

How Did You Start Programming? 74 comments

With the recent brouhaha about vulnerabilities in many relatively recent processors, I got to thinking back to the time when I first started programming. Back then, things seemed so much simpler and much more straightforward.

To start off the new year, I thought it might be interesting to find out how people got their start in programming.

My first exposure to programming was by means of a Teletype over a dialup line using an acoustical coupler to a PDP-8 computer running TSS/8 and which had 24 KB of RAM. At the time, Star Trek ToS was on the air, and I thought this was the new, big thing. I was quickly disappointed by it not measuring up to anything like what I saw on TV, but I saw it had promise. Started with BASIC (and FOCAL). Later on was exposed to a PDP-11 running RSTS/E and programmed in BASIC+ as well as some Pascal.

As for owning a computer, the first one I bought was an OSI[*] Challenger 4P with a whopping 4KB of RAM!

From those humble beginnings, I ate up everything I could lay my hands on and later worked for a wide variety of companies that ranged in size from major internationals to tiny startups. Even had a hand in a project for Formula 1!

So, my fellow Soylentils, how did you get started programming? Where has it taken you?

[*] One day when my girlfriend came over and saw the OSI logo on my computer her eyes got huge! You see, The Six Million Dollar Man was on television at that time, and she suddenly suspected I was connected to the "Office of Scientific Intelligence"!


Original Submission

Qualcomm Joins Others in Confirming its CPUs Suffer From Spectre, and Other Meltdown News 31 comments

Arthur T Knackerbracket has found the following story:

Qualcomm has confirmed its processors have the same security vulnerabilities disclosed this week in Intel, Arm and AMD CPU cores this week.

The California tech giant picked the favored Friday US West Coast afternoon "news dump" slot to admit at least some of its billions of Arm-compatible Snapdragon system-on-chips and newly released Centriq server-grade processors are subject to the Meltdown and/or Spectre data-theft bugs.

[...] Qualcomm declined to comment further on precisely which of the three CVE-listed vulnerabilities its chips were subject to, or give any details on which of its CPU models may be vulnerable. The paper describing the Spectre data-snooping attacks mentions that Qualcomm's CPUs are affected, while the Meltdown paper doesn't conclude either way.

[...] Apple, which too bases its iOS A-series processors on Arm's instruction set, said earlier this week that its mobile CPUs were vulnerable to Spectre and Meltdown – patches are available or incoming for iOS. The iGiant's Intel-based Macs also need the latest macOS, version 10.13.2 or greater, to kill off Meltdown attacks.

What Impact Has Meltdown/Spectre Had on YOUR Systems? 47 comments

SoylentNews first reported the vulnerabilities on January 3. Since then, we have had a few stories addressing different reports about these vulnerabilities. Now that it is over two weeks later and we are *still* dealing with reboots, I am curious as to what our community's experience has been.

What steps have you taken, if any, to deal with these reports? Be utterly proactive and install every next thing that comes along? Do a constrained roll out to test a system or two before pushing out to other systems? Wait for the dust to settle before taking any steps?

What providers (system/os/motherboard/chip) have been especially helpful... or non-helpful? How has their response affected your view of that company?

What resources have you been using to check on the status of fixes for your systems? Have you found a site that stands above the others in timeliness and accuracy?

How has this affected your purchasing plans... and your expectations on what you could get for selling your old system? Are you now holding off on purchasing something new?


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1) 2
  • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:05PM (27 children)

    by Anonymous Coward on Wednesday January 03 2018, @05:05PM (#617216)

    Cloud providers will get fixed VMs to better isolate customers' resources, and programs will be re-written to consolidate/batch syscalls, so as to avoid context switching.

    Consumers who would notice the a performance hit will just get an "Optimize for Performance" setting that will disable the workaround when playing video games, etc.

    • (Score: 1, Insightful) by Anonymous Coward on Wednesday January 03 2018, @05:26PM (23 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:26PM (#617229)

      I doubt the average Joe benefits in any way from this patch. Anything worth knowing about a system like that already resides in ring3 and is readily grabbable if the user allows random code to execute (which is a necessity to leverage this). Unless this allows code to be injected into ring0 I don't see how this is as severe as it is made out to be from the scant information that is available right now. There are trivial ways to defeat ASLR type defenses if code is allowed to execute and the offset of the code in the file is known, simple arithmetic, no exploit.

      • (Score: 4, Insightful) by TheRaven on Wednesday January 03 2018, @05:46PM (22 children)

        by TheRaven (270) on Wednesday January 03 2018, @05:46PM (#617243) Journal

        It's still under embargo (and was meant to be until the 9th, but the Linux people were oh-so-clever and leaked it - I hope Intel won't give them embargoed security reports in the future), so this is speculation:

        If this were just a KASLR bypass, it some of the people who are preparing patches wouldn't be involved, so it's almost certainly more than that. It's either kernel memory disclosure or kernel memory modification. In either case, normal users should care because they typically rely on the kernel for sandboxing. If you run Chrome, Edge, or Safari, the part of the program that deals with untrusted data is run in a de-privileged process with fairly narrow communication channels to the parent. Going from being able to inject code that can trigger, for example, a libpng or libavcodec vulnerability in the browser to being able to run code outside of this process usually requires chaining together a load of different vulnerabilities. With this, you have the possibility of writing an exploit that works reliably on any x86 operating system and browser and will let you jump out of the sandbox. That's very bad. Even if it's 'just' arbitrary kernel memory disclosure, there are often ways of turning that into privilege escalation.

        --
        sudo mod me up
        • (Score: 5, Insightful) by takyon on Wednesday January 03 2018, @05:48PM (7 children)

          by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @05:48PM (#617246) Journal

          (and was meant to be until the 9th, but the Linux people were oh-so-clever and leaked it - I hope Intel won't give them embargoed security reports in the future)

          I hope Intel loses market share and billions of dollars because of this.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
          • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @06:01PM

            by Anonymous Coward on Wednesday January 03 2018, @06:01PM (#617258)

            Haven't you heard? The new business strategy is:

            1. Get enough market share and label yourself "too big to fail"
            2. Do whatever you can to get the most money
            3. Cry when things go bad, get bailed out

            It is a pretty foolproof plan, the hard part is getting the initial market share. After that you pay some idiots to push PR and you continue business as usual. Perhaps we'll get a miracle, I'm sure AMD will get a nice bump, but I'm not gonna hold my breath.

          • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @07:56PM (4 children)

            by Anonymous Coward on Wednesday January 03 2018, @07:56PM (#617312)

            Intel will likely throw some money around behind the scenes to ensure that Microsoft, Apple and Red Hat do not make a conditional check in their kernels that lets AMD cpus run unfettered.

            Of course it will be termed exactly that way - "too complicated to conditionally implement (for small minority of our customers)", along with some form of "you amd fanbois can choose a cup or a towel for your tears" conceit.

            At least from Linux side it looks like a simple flag to bypass the problem for AMD, perhaps with a kernel recompile. But I'm sure Pottering and its minions are working on a way to "fix" things in systemd too.

            • (Score: 2) by Grishnakh on Wednesday January 03 2018, @08:08PM (2 children)

              by Grishnakh (2831) on Wednesday January 03 2018, @08:08PM (#617318)

              Intel will likely throw some money around behind the scenes to ensure that Microsoft, Apple and Red Hat do not make a conditional check in their kernels that lets AMD cpus run unfettered.... At least from Linux side it looks like a simple flag to bypass the problem for AMD, perhaps with a kernel recompile. But I'm sure Pottering and its minions are working on a way to "fix" things in systemd too.

              Red Hat is only one of many, many Linux distros. Debian surely wouldn't adopt such a thing, since Debian isn't even a corporation, and all the Debian derivatives are unlikely to follow RH's lead too.

              As for systemd, that seems like a silly accusation. systemd is many things, but it's not a kernel, and AFAICT here, this fix is something purely inside the kernel, not something that could somehow be baked into systemd to force all kernels on both Intel and AMD CPUs to work this way.

              No, I think this is something that Intel isn't going to be able to hide from with any shenanigans. It's just too easy to use a different Linux distro, or compile your own kernel, esp. if the kernel team isn't complicit and makes it easy to enable or disable this fix depending on the CPU it's running on (they could perhaps even make it automatic--a simple runtime check at kernel boot-up could allow the kernel to see what it's running on and adopt the correct strategy). Then it'll be easy for anyone who can run some benchmarks on Linux to show just how awful performance is on Intel CPUs compared to AMD ones, and publish the results.

              What sucks is that the selection of AMD CPUs just isn't very good: I can't easily purchase a business-grade laptop with an AMD processor. Lenovo doesn't use them, Dell doesn't use them (for the Latitudes), and HP doesn't use them (for their ugly business laptops, whatever they're called). You have to resort to some plastic-cased crappy-keyboard consumer laptop to get an AMD, as far as I can tell. Hopefully the business laptop makers will start offering AMDs now.

              • (Score: 4, Funny) by driverless on Thursday January 04 2018, @03:44AM (1 child)

                by driverless (4770) on Thursday January 04 2018, @03:44AM (#617500)

                As for systemd, that seems like a silly accusation. systemd is many things, but it's not a kernel

                Has anyone told systemd that?

                • (Score: 2) by crafoo on Thursday January 04 2018, @08:22AM

                  by crafoo (6639) on Thursday January 04 2018, @08:22AM (#617585)

                  I'm pretty sure SunnyD is a mostly successful attempt by the NSA to co-opt and backdoor linux.

            • (Score: 3, Insightful) by NewNic on Thursday January 04 2018, @01:24AM

              by NewNic (6420) on Thursday January 04 2018, @01:24AM (#617454) Journal

              Microsoft, maybe. But RedHat can't afford to do this, since it the first person who looks at their kernel packages (no doubt someone at AMD) will discover what has been done and cry foul!

              --
              lib·er·tar·i·an·ism ˌlibərˈterēənizəm/ noun: Magical thinking that useful idiots mistake for serious political theory
          • (Score: 1) by fustakrakich on Thursday January 04 2018, @04:34AM

            by fustakrakich (6150) on Thursday January 04 2018, @04:34AM (#617513) Journal

            I hope Intel loses market share

            To whom? We don't have the alpha chip anymore. Maybe IBM's power chip can come through...

            --
            La politica e i criminali sono la stessa cosa..
        • (Score: 1, Interesting) by Anonymous Coward on Wednesday January 03 2018, @05:50PM

          by Anonymous Coward on Wednesday January 03 2018, @05:50PM (#617248)

          Leave non-Internetty things running as usual.

          Hell, you could even run certain trusted website code without the new protections. It just won't matter in the end; all of the headache will belong to the programmers, not the users.

        • (Score: 5, Informative) by Anonymous Coward on Wednesday January 03 2018, @05:55PM (8 children)

          by Anonymous Coward on Wednesday January 03 2018, @05:55PM (#617250)

          The key detail was leaked on the linux-kernel mailing list, but not by some random Linux developer. It was leaked by an AMD employee who was providing a patch to exclude AMD processors from the bug work-around.

          • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:56PM

            by Anonymous Coward on Wednesday January 03 2018, @05:56PM (#617253)

            Might be FUD in that case. The bug is certainly real, but if all the speculation is based on that it's pretty suspect.

          • (Score: -1, Informative) by Anonymous Coward on Wednesday January 03 2018, @06:19PM (1 child)

            by Anonymous Coward on Wednesday January 03 2018, @06:19PM (#617267)
             
            • (Score: -1, Offtopic) by Anonymous Coward on Wednesday January 03 2018, @06:27PM

              by Anonymous Coward on Wednesday January 03 2018, @06:27PM (#617270)

              Is this rabid praise or feral bleating?

          • (Score: 3, Informative) by MrGuy on Wednesday January 03 2018, @07:28PM (2 children)

            by MrGuy (1007) on Wednesday January 03 2018, @07:28PM (#617302)

            Wait - what??? Citation needed.

            If I read your comment correctly, the flaw was identified, and a fix was identified, on the linux-kernel mailing list. That's a public forum. [lkml.org]

            You're saying an AMD employee making a patch ON TOP OF the patch to fix the Intel issue to exclude unaffected AMD processors is the point where the issue was "leaked" to the public?

            How does THAT work? How could the AMD patch to exclude AMD processors precede a discussion/patch to fix the issue on Intel processors? There was zero discussion on the linux-kernel list of the issue before the AMD patch-to-a-patch was suggested?

            • (Score: 4, Informative) by Anonymous Coward on Wednesday January 03 2018, @08:09PM

              by Anonymous Coward on Wednesday January 03 2018, @08:09PM (#617320)

              https://lkml.org/lkml/2017/12/27/2 [lkml.org]

              His second sentence gives away the key info.

              Prior to that, the description of the bug was still pretty vague. Now we have some excellent guesses. We can be almost certain that this is a timing-related attack on the kernel address space.

            • (Score: 2) by stretch611 on Thursday January 04 2018, @05:24PM

              by stretch611 (6199) on Thursday January 04 2018, @05:24PM (#617812)

              While an AMD employee did go into details about the reason for the patch...

              He did so to explain why AMD processors are not affected by the bug.

              Also, it should be noted that some reports are mentioning at 5-30% performance decrease due to the patch. (mostly on server workloads such as databases)

              Now, If you were working at Intel, wouldn't you prefer the patch to decrease the competitor's performance just as bad as yours is being hit?

              I mean if the AMD employee did not speak up, the patch would have slowed down AMD processors unnecessarily. Now AMD can boast a relative boost in server performance over Intel, while also mentioning that they are not creating additional maintenance costs due to the workload of installing software patches to correct bad hardware.

              Mind you, this is one of the specific flaws being patched, not all that are likely happening. Also, based on the comments to the maillist message here [lkml.org], provided by an AC in this discussion. The comments in the message clearly show that "/* Assume for now that ALL x86 CPUs are insecure */" until the AMD employee provided code to bypass the fix along with an explanation for AMD processors.

              --
              Now with 5 covid vaccine shots/boosters altering my DNA :P
          • (Score: 2) by TheRaven on Thursday January 04 2018, @09:09AM (1 child)

            by TheRaven (270) on Thursday January 04 2018, @09:09AM (#617591) Journal
            That email wouldn't have happened if other Linux developers were not committing patches in public, during the embargo period. The AMD email just said 'we're not vulnerable to this', it was the previous patch set that made enough information public for people to be able to guess the vulnerability.
            --
            sudo mod me up
            • (Score: 2) by moondrake on Thursday January 04 2018, @10:17PM

              by moondrake (2658) on Thursday January 04 2018, @10:17PM (#618011)

              the patches were pretty cryptic to almost all people.

              AMD specified what exactly your "this" is.

              So it is a little bit unfair to put the blame on linux. We already knew from NT kernels that something was going on related to memory management.

              Of course, you could spin it to blame linux .

        • (Score: 2) by takyon on Wednesday January 03 2018, @06:12PM (3 children)

          by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @06:12PM (#617264) Journal

          I hope Intel won't give them embargoed security reports in the future

          Maybe we should give Intel's CEO a jail cell for selling as much stock as possible during the embargo.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
          • (Score: 2) by frojack on Wednesday January 03 2018, @07:05PM

            by frojack (1554) on Wednesday January 03 2018, @07:05PM (#617289) Journal

            Since they sell stock as a matter of pre-programmed trades (outside of their personal control), any change of pattern during the embargo would constitute insider trading.

            --
            No, you are mistaken. I've always had this sig.
          • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @07:53AM

            by Anonymous Coward on Thursday January 04 2018, @07:53AM (#617580)

            I'm sure he's too rich to jail.

          • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @11:31AM

            by Anonymous Coward on Thursday January 04 2018, @11:31AM (#617621)

            He'll just run to the safe haven that is Intel's home now. Which speaks volumes.

    • (Score: 2) by DannyB on Wednesday January 03 2018, @05:46PM (2 children)

      by DannyB (5839) Subscriber Badge on Wednesday January 03 2018, @05:46PM (#617244) Journal

      Non Cloud users can get a new sticker from Intel to affix to their computer.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
      • (Score: 1, Touché) by Anonymous Coward on Thursday January 04 2018, @01:44AM (1 child)

        by Anonymous Coward on Thursday January 04 2018, @01:44AM (#617457)

        intel bugs inside

        • (Score: 2) by DannyB on Thursday January 04 2018, @03:43PM

          by DannyB (5839) Subscriber Badge on Thursday January 04 2018, @03:43PM (#617733) Journal

          The sticker is to re-assure them that everything is okay. Nothing to see-hear. Move along. Move along.

          --
          People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:07PM (2 children)

    by Anonymous Coward on Wednesday January 03 2018, @05:07PM (#617217)

    The Linux fix can be disabled, which you will likely want to do if you use an AMD processor.

    My understanding (I've not read the patch set) is that the kernel will still maintain the trampoline stack to preserve KASLR?

  • (Score: 5, Funny) by fyngyrz on Wednesday January 03 2018, @05:09PM (7 children)

    by fyngyrz (6567) on Wednesday January 03 2018, @05:09PM (#617218) Journal

    Apple: We might see some backlash for making people's phones run slower.

    Intel: Hold my beer…

    • (Score: 1, Insightful) by Anonymous Coward on Wednesday January 03 2018, @05:36PM (2 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:36PM (#617235)

      Intel is actually seeing a backlash for making people's computers run faster.

      It turns out that Intel's cleverness isn't secure.

      • (Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @02:31AM (1 child)

        by Anonymous Coward on Thursday January 04 2018, @02:31AM (#617468)

        Ok who let in Professor Pedantic? Give em' a beer and kick em' out!

        • (Score: 2) by stretch611 on Thursday January 04 2018, @03:24PM

          by stretch611 (6199) on Thursday January 04 2018, @03:24PM (#617723)

          Why waste a beer on buzz-kills

          --
          Now with 5 covid vaccine shots/boosters altering my DNA :P
    • (Score: 4, Informative) by Anonymous Coward on Wednesday January 03 2018, @05:57PM (3 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:57PM (#617255)

      The bug is in some 64-bit ARM processors as well. Apple makes those for the iPhone.

      • (Score: 4, Informative) by bob_super on Wednesday January 03 2018, @06:46PM

        by bob_super (1357) on Wednesday January 03 2018, @06:46PM (#617280)

        Apple also sells a lot of Intel-based machines ...

      • (Score: 2) by Azuma Hazuki on Wednesday January 03 2018, @08:21PM (1 child)

        by Azuma Hazuki (5086) on Wednesday January 03 2018, @08:21PM (#617330) Journal

        I don't know who modded you down but you get a +1 Informative from me. How in the hell could what you posted be considered Flamebait anyway?

        --
        I am "that girl" your mother warned you about...
        • (Score: 2) by takyon on Wednesday January 03 2018, @08:55PM

          by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @08:55PM (#617343) Journal

          Here's some sauce from El Reg:

          And it appears 64-bit ARM Linux kernels will also get [lwn.net] a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR.

          Ars [arstechnica.com]:

          While Intel systems are the ones known to have the defect, they may not be the only ones affected. Some platforms, such as SPARC and IBM's S390, are immune to the problem, as their processor memory management doesn't need the split address space and shared kernel page tables; operating systems on those platforms have always isolated their kernel page tables from user mode ones. But others, such as ARM, may not be so lucky; comparable patches for ARM Linux are under development.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:23PM (12 children)

    by Anonymous Coward on Wednesday January 03 2018, @05:23PM (#617224)

    There chips have been suspect since the original pentium, and are suspiciously defective by design, I haven't bought one that wasn't a laptop since my XT which admittedly had the best and easiest to access case I ever had

    • (Score: 4, Informative) by Anonymous Coward on Wednesday January 03 2018, @05:55PM (8 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:55PM (#617252)

      It just so happens that the best stuff is still mediocre.

      • People want x86 processors.

        People want drivers that work; Intel's Linux support has been pretty strong, while AMD GPUs not so much.

      • Alternative architecures suck.

        POWER stuff is built for high-end servers.

        ARM stuff is built for OEM secrecy. Seriously; that shit is not FOSS friendly.

        RISC-V is vaporware.

        Other processors are for low-end and embedded stuff.

      • (Score: 2) by The Mighty Buzzard on Thursday January 04 2018, @03:37AM (4 children)

        by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Thursday January 04 2018, @03:37AM (#617494) Homepage Journal

        You haven't paid much attention to what's gone on with AMD's linux drivers the past year or two, have you?

        --
        My rights don't end where your fear begins.
        • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @03:48AM (3 children)

          by Anonymous Coward on Thursday January 04 2018, @03:48AM (#617503)

          I'm talking nearly 2 decades.

          • (Score: 1, Informative) by Anonymous Coward on Thursday January 04 2018, @04:59AM (2 children)

            by Anonymous Coward on Thursday January 04 2018, @04:59AM (#617519)

            Wait, when did Intel release that crappy 740 thingy? Ah, yes, 20 years ago. https://en.wikipedia.org/wiki/Intel740 [wikipedia.org] And all the crappy integrated video? Same era starting with the 815, but crappy all the time, lagging behind everyone else. https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units [wikipedia.org] I don't remember drivers for the 740, the rest, yes, crappy HW, crappy SW and with a lot of NIH (current Mesa stack shares a lot from one driver to another... except Intel, that go with own code paths a lot).

            We had acceptable ATI drivers for Linux in late 90s, up to R100 (someone paid for the work in those) or R200. https://lists.centos.org/pipermail/centos/2005-July/006762.html [centos.org] Then they went a bit asshole mode, around R300, but finally saw the light (probably due to AMD acquisition) and now you ca get open driver that work acceptably at launch or just a bit after. In some cases, it seems they end providing the same speed than closed drivers.

            Just recently Intel announced chips with AMD video. https://www.anandtech.com/show/12003/intel-to-create-new-8th-generation-cpus-with-amd-radeon-graphics-with-hbm2-using-emib [anandtech.com]

            • (Score: 1) by WillR on Thursday January 04 2018, @02:39PM (1 child)

              by WillR (2012) on Thursday January 04 2018, @02:39PM (#617683)

              Then they went a bit asshole mode, around R300

              R300 GPUs came out in late 2002.

              but finally saw the light (probably due to AMD acquisition) and now you ca get open driver

              And the new amdgpu driver just landed in kernel 4.14. If you use Debian stable, AMD might make it to 20 years of shit drivers too.

              • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @10:25PM

                by Anonymous Coward on Thursday January 04 2018, @10:25PM (#618018)

                Sorry, you are wrong, 4.12 has AMDGPU driver, enough to use a RX580 fully accelerated 2D and OpenGL 4.5 with Mesa 17.3. Looking at old kernel configs, 4.4 mentions AMDGPU, so that version or even older; 4.14 probably adds more features (and so will 4.15, 4.16, etc). Maybe it adds the Vega family (the next after RX5xx), but those are really hard to find... the shops I hit this week only had up to RX580 for sale, and some were in backorder.

                In other words, all the GCN families (RX5xx and older) and the previous families (Evergreen, R700 to R100) are supported, from personal experience for >5 years, which includes past Debian Stable. In some cases, better than the privative drivers ever did, in others just slighly slower.

      • (Score: 2) by Wootery on Thursday January 04 2018, @09:46AM (2 children)

        by Wootery (2341) on Thursday January 04 2018, @09:46AM (#617598)

        MIPS is still going, too. Last year they made a multicore CPU for safety-critical systems. [imgtec.com] Embedded, as you say.

        SPARC is dead, Alpha is long dead, SuperH is going nowhere even with the Free 'J2' implementation.

        Not heard anything about VIA for the longest time.

    • (Score: 1) by Crash on Wednesday January 03 2018, @08:10PM

      by Crash (1335) on Wednesday January 03 2018, @08:10PM (#617321)

      Claiming haven't done X, except for Y... Doesn't count.

      I actually have never purchased an Intel CPU, and it was a complete PITA trying to find a laptop in 2015.

      This AMD version of the Lenovo IdeaPad Y700 [newegg.com] wasn't even listed on Lenovo's own damned website!

    • (Score: 2) by Grishnakh on Wednesday January 03 2018, @08:11PM (1 child)

      by Grishnakh (2831) on Wednesday January 03 2018, @08:11PM (#617324)

      since my XT which admittedly had the best and easiest to access case I ever had

      Huh? You must have been buying a lot of crappy cases then. There've been tons of cases since the XT days which were better and easier to access. If you have to use a screwdriver to open the case, it's really not that easy to access. If you have to use a screwdriver to remove any of the drives, it's really not easy to access.

      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @10:01PM

        by Anonymous Coward on Wednesday January 03 2018, @10:01PM (#617377)

        Granted, mine was an XT clone, but...

        It was a full-size case that lay flat. You'd put a monitor on top probably. The sides had hinges at the rear and release buttons at the front. Put one hand on each side near the front, press the buttons, and lift. The top half of the case, excluding the front panel (drive bays and speaker) and rear panel (card slot openings and power cord) would lift up. It even had something to keep it from falling down.

        I like the screws better, at least if they go into something solid that won't strip. Screws are light weight and won't open by accident.

  • (Score: 2) by Justin Case on Wednesday January 03 2018, @05:26PM (8 children)

    by Justin Case (4239) on Wednesday January 03 2018, @05:26PM (#617227) Journal

    From what we know so far, this sounds like a privilege escalation and/or cross-VM flaw.

    Will Joe Sixpack or Grandma care? Especially when they either run as admin already, or whack-a-mole click OK on everything that pops up.

    • (Score: 2) by takyon on Wednesday January 03 2018, @05:34PM (1 child)

      by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @05:34PM (#617232) Journal

      Let's see what happens to Windows computers on Patch Tuesday. If almost all personal computers worldwide slow down, will Grandma Sixpack notice?

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 2, Touché) by Anonymous Coward on Wednesday January 03 2018, @05:36PM

        by Anonymous Coward on Wednesday January 03 2018, @05:36PM (#617236)

        The bright side is that the already barely useable crapware that modern software has devolved into should become completely unuseable if the performance hit on windows is as severe as the one in implied for linux. Maybe brogrammers will be forced to optimize their warez again.

    • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:38PM (2 children)

      by Anonymous Coward on Wednesday January 03 2018, @05:38PM (#617237)

      Yes, they'll care. Javascript on any web page being able to access kernel memory is a Really Bad Thing.

      They probably WON'T care about a 33% CPU slowdown.

      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:40PM (1 child)

        by Anonymous Coward on Wednesday January 03 2018, @05:40PM (#617239)

        "access" and "guess/deduct things about" are not the same thing.

        • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @05:47PM

          by Anonymous Coward on Wednesday January 03 2018, @05:47PM (#617245)

          Meaning you can inject code into privileged pages, but not read out the contents of them, by inferring the timing of the page walks for where an address is in relation to your code.

    • (Score: 4, Interesting) by TheRaven on Wednesday January 03 2018, @05:48PM

      by TheRaven (270) on Wednesday January 03 2018, @05:48PM (#617247) Journal

      Will Joe Sixpack or Grandma care? Especially when they either run as admin already, or whack-a-mole click OK on everything that pops up.

      Yes, because even when they run as admin, programs such as web browsers and mail clients (and dchp clients and so on) that expect to deal with untrusted data will drop privileges from child processes that are exposed to an attacker. That normally gives you a lot of protection, but it amounts to nothing when the CPU lets you bypass any kernel security mechanism and go from code running in an unprivileged process to code running in ring 0.

      --
      sudo mod me up
    • (Score: 3, Informative) by TheRaven on Thursday January 04 2018, @09:36AM

      by TheRaven (270) on Thursday January 04 2018, @09:36AM (#617594) Journal
      There are a few more details out now. The basic vulnerability works as follows:

      You make the CPU speculate execution and down a path that involves accessing memory that you shouldn't have access to. You make sure that there is a conditional branch in the result that depends on the value of a byte that you shouldn't read. You measure the time that it takes to execute a sequence of instructions including the speculatively executed (but cancelled) instructions. This tells you the value of a single bit in the target address. You then repeat until you've read as much memory as you want to.

      This is an oversimplification, because the exact conditions depend on which things are in cache.

      So, this is probably not quite as bad as I thought. For a sandbox escape, you'd need a kernel interface that depended on a secret to escape, which shouldn't exist. That, a web page would be able to (eventually) exfiltrate your SSH private key if it's in memory (including in the buffer cache) and then the attacker could just ssh into your machine. That said, it's likely to peg your CPU at 100% for quite a long time to get anything meaningful (it takes quite a few thousand cycles to get a single bit, and unless you know exactly where the keys are already then you're going to have to read quite a few pages to be able to locate them. For now, just killing anything that looks as if it's eating more CPU than it deserves should keep you fairly safe.

      --
      sudo mod me up
    • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @05:07PM

      by Anonymous Coward on Thursday January 04 2018, @05:07PM (#617796)

      does grandma run the server farm in that yonder cloud? If so, she'll care.

      if not, she'll wonder why it takes to long to initiate a game of slingo on aol because it'll be 30% slower on all the topology that runs it--and it'll effect those open stack hardware platforms that have 'virtual switches' running in some hypervisor.

      it's defects almost all the way down

  • (Score: 5, Interesting) by takyon on Wednesday January 03 2018, @05:43PM (3 children)

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @05:43PM (#617241) Journal

    Search for "Brian Krzanich stock". [google.com]

    No results for the Dec. 19th Motley Fool story.

    A search for "Motley Fool" [google.com] brings up the news source repeatedly, so the news source is not delisted from Google News.

    Tom's Hardware says [tomshardware.com]:

    Intel CEO Brian Krzanich also recently sold $11 million in stock, which some have proclaimed is a sign that he's unloading his shares before a pending disaster. However, Krzanich sold the stock under a 10b-51 plan, which is a pre-planned sale of stocks intended to prevent insider trading. The nature of Krzanich's transactions makes it unlikely that the trades are a precursor of a major monetary loss for the company.

    However, the Dec. 19th Motley Fool story says:

    What's interesting, then, is that before Krzanich made any of the transactions that he reported in his most recently filed Form 4, he held 495,743 shares.

    After the options exercises and subsequent sales (which left Krzanich's position unchanged at 495,743 shares), Krzanich then made two more transactions: a sale of 242,830 shares and a sale of 2,913 shares, with each transaction happening at an average price of $44.555, per the filing.

    Those two transactions left Krzanich with exactly 250,000 shares -- the bare minimum that he's required to hold as CEO.

    [...] Instead, given that Krzanich seems to have sold all the shares he could save for those he is required by Intel's corporate bylaws to hold, the impression that I get is that Krzanich doesn't have a ton of faith in the potential for Intel stock to appreciate, perhaps driven by a lukewarm (or potentially even negative) view of the company's near- to medium-term business prospects.

    After all, considering that Intel CFO Robert Swan reportedly said in a memo seen by The Oregonian that the company aims to boost its market capitalization to $300 billion (implying a share price north of $60) by 2021, wouldn't it have been wiser for Krzanich to hold those shares, collecting about a quarter of a million dollars per year in dividend payouts, before until they gained another $16 in value each, totaling nearly $4 million in additional value?

    Indeed, considering that Krzanich claimed back in February that Intel's total addressable market is now on track to hit $220 billion by 2021, it seems strange that with all these growth opportunities ahead of Intel he'd choose to keep only the shares that he's required to by Intel's rules.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 3, Informative) by frojack on Wednesday January 03 2018, @07:56PM (2 children)

      by frojack (1554) on Wednesday January 03 2018, @07:56PM (#617313) Journal

      Never trust Motley Fool. Any random joe can post there and you have to read a mountain of replies to see if he even knows what he is talking about.

      All Krzanich's trades [yahoo.com] have been programmed trades and automatic sales. He has no involvement in these. He's following best practices to avoid holding too much intc stock such that every daily decision he has to makes would be tainted by charges of feathering his own nest.

      A CEO is a hired manager. He's supposed to look out for the company, not his own holdings. You want to look for insider trading you won't find it among the day to day operators. Check out the institutional holders [yahoo.com]. Those guys have huge exposures, any one of which exceeds ALL of the insiders, and those institutions do that sort of stuff all the time.

      In fact all Krzanich's large Automatic sales are concurrent with Open market Options Executions (programmed) for very large amounts.
      He's pretty much hands off on intc holdings, as required by law. Its all pre-programmed formula driven trades [investopedia.com] and not handled by him.

      Yet there is always someone who jumps up and claims insider trading on automated trades dictated by the Rule 10b-5 plan. And most of the time you find them posting on Motley Fool.

      There's no there there.

      --
      No, you are mistaken. I've always had this sig.
      • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @07:59AM

        by Anonymous Coward on Thursday January 04 2018, @07:59AM (#617583)

        And how exactly do you know that the time of outing of this bug was not pre-programmed?

      • (Score: 2) by takyon on Friday January 05 2018, @08:09AM

        by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Friday January 05 2018, @08:09AM (#618263) Journal

        Intel CEO sold all the stock he could after Intel learned of security bug [arstechnica.com]

        While an Intel spokesperson told CBS Marketwatch reporter Jeremy Owens that the trades were "unrelated" to the security revelations, and Intel financial filings showed that the stock sales were previously scheduled, Krzanich scheduled those sales on October 30. That's a full five months after researchers informed Intel of the vulnerabilities. And Intel has offered no further explanation of why Krzanich abruptly sold off all the stock he was permitted to.

        As a result of his stock sale, Krzanich received more than $39 million. Intel stock, as of today, is trading at roughly the same price as Krzanich sold stock at, so he did not yield any significant gain from selling before the vulnerability was announced. But the sale may still bring scrutiny from the Securities and Exchange Commission for a number of reasons.

        The Rule 10b5-1 plan under which Krzanich scheduled the stock sale is intended to shield executives from accusations of insider trading. But because of the timing of the plan and the length of time Intel kept the vulnerability secret, SEC officials could still see the maneuver as a trade based on insider information—especially if there was no other material reason for Krzanich to sell the stock.

        --
        [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
  • (Score: 4, Interesting) by Anonymous Coward on Wednesday January 03 2018, @06:09PM

    by Anonymous Coward on Wednesday January 03 2018, @06:09PM (#617262)

    The currently proposed fix still leaves a little bit of kernel code mapped. The assembly code for entry and exit is still mapped in. It is this code that updates CR3, which points at the page table tree, to do the memory mapping isolation.

    An x86 processor has a built-in capability to do that.

    The GDT, IDT, and TSS are all in virtual memory. If a normal fault, such as an IRQ or system call, is unable to be handled then you get a doublefault. (if that can't be handled then you get a triplefault which resets the CPU) Any fault can be make to do a task switch. Hardware task switching loads a new CR3 value, which changes all of virtual memory. That means it changes the GDT, IDT, and TSS.

    So you don't need any kernel code mapped at all. You don't need even one byte mapped.

    Historically, the task switch mechanism has been avoided due to slowness. Much of that comes from loading CR3... which we're now doing anyway. We might as well let the hardware do that, letting us gain the advantage of having no code mapped.

  • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @06:53PM (1 child)

    by Anonymous Coward on Wednesday January 03 2018, @06:53PM (#617286)

    Attorney files massive class action lawsuit for trillion$.

  • (Score: 2) by looorg on Wednesday January 03 2018, @07:25PM (11 children)

    by looorg (578) on Wednesday January 03 2018, @07:25PM (#617299)

    Considering there will be billions of unpatched machines with an Intel CPU at its core I do wonder how screwed they'll be or how high the risk will be to run unpatched machines at home. I doubt a lot of people would want to take a 30% performance hit. Gamers and people that run a lot of computations would want that.

    • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @07:33PM

      by Anonymous Coward on Wednesday January 03 2018, @07:33PM (#617303)

      As long as nothing can execute (so no web scripting or running untrusted code) and thus leverage the attack (whatever it turns out to be) it shouldn't matter. Both of these things are already unadviseable to do and can be avoided.

    • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @07:35PM (9 children)

      by Anonymous Coward on Wednesday January 03 2018, @07:35PM (#617304)

      The figures are 0.28 - 5%. The worst case figures are for unrealistic syscall, heavy synthetic benchmarks where the ~20% figure is for database servers (additional context switch overhead). The performance hit will not be as severe on more modern processors with PCID.

      • (Score: 2, Funny) by Anonymous Coward on Wednesday January 03 2018, @07:38PM

        by Anonymous Coward on Wednesday January 03 2018, @07:38PM (#617307)

        syscall, heavy

        Should have been "syscall-heavy" but readers are welcome to read it in your best Shatner voice for dramatic effect.

      • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @08:03PM (6 children)

        by Anonymous Coward on Wednesday January 03 2018, @08:03PM (#617315)

        I've seen the figure given as:
        5-35% (the title of the summary here)
        "upwards of 30%" (aka 30% is the minimum performance hit, not the maximum) elsewhere
        and not 0.28-5% in your comment.
        Which of these is real?

        • (Score: 2) by takyon on Wednesday January 03 2018, @08:11PM (3 children)

          by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @08:11PM (#617323) Journal

          Synthetic benchmarks seem to be impacted, gamers might not be impacted at all.

          http://www.legitreviews.com/intel-cpu-bug-bring-massive-performance-hit-applications_201307 [legitreviews.com]

          https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti [phoronix.com]
          https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests [phoronix.com]

          Things will be more clear in a week or two.

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
          • (Score: 2) by TheLink on Thursday January 04 2018, @02:52AM (2 children)

            by TheLink (332) on Thursday January 04 2018, @02:52AM (#617473) Journal
            I wonder how benchmark/review sites and similar are going to handle the aftermath of the workarounds to Spectre and Meltdown etc...

            Will they add guesstimate adjustments to old benchmarks that would likely be affected? Splitting the benchmarks to "before" and "after" won't be helpful to people trying to compare older CPUs with new ones.

            Redoing all the old benchmarks might not be practical or possible.
            • (Score: 2) by takyon on Thursday January 04 2018, @03:02AM (1 child)

              by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Thursday January 04 2018, @03:02AM (#617478) Journal

              Run 'em twice?

              Again, games don't seem to be showing any big frame drops yet (maybe the right CPU-heavy game will do it).

              If there is a significant difference, they could include unpatched and patched Intel alongside each other.

              We'll see. Maybe check the AnandTech tweets: https://www.anandtech.com [anandtech.com]

              --
              [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
              • (Score: 2) by TheLink on Thursday January 04 2018, @03:34AM

                by TheLink (332) on Thursday January 04 2018, @03:34AM (#617492) Journal
                <quote>Run 'em twice?</quote>
                Not so easy to do the benchmarks all over again when you've done hundreds over many years. You may not have the hardware lying around anymore.

                <quote>Again, games don't seem to be showing any big frame drops yet (maybe the right CPU-heavy game will do it).</quote>
                In most real world cases the main bottleneck for new games is the GPU. But there might be changes for "minimum FPS" encountered or time under 30fps.

                The less "synthetic" CPU benchmarks would probably be affected too.

                I'd be interested to see the SSD and DB benchmarks since those also involve a fair number of kernel calls per second.
        • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @09:42PM (1 child)

          by Anonymous Coward on Wednesday January 03 2018, @09:42PM (#617364)

          The 2.8% was from one of the KEISER papers, the 5% figure from a kernel dev, reproduced here: https://en.wikipedia.org/wiki/Kernel_page-table_isolation#Implementation [wikipedia.org]

          • (Score: 0) by Anonymous Coward on Wednesday January 03 2018, @09:47PM

            by Anonymous Coward on Wednesday January 03 2018, @09:47PM (#617368)

            0.28% damn, I got it right from memory but not copying direct from a source. Too much time following this, I'm off to drink, heavily.

      • (Score: 1, Interesting) by Anonymous Coward on Wednesday January 03 2018, @09:10PM

        by Anonymous Coward on Wednesday January 03 2018, @09:10PM (#617349)

        The problem is that PCID support was only added to the Linux kernel in 2017, so no LTS kernel has that support.

  • (Score: 3, Informative) by takyon on Wednesday January 03 2018, @08:57PM (7 children)

    by takyon (881) <reversethis-{gro ... s} {ta} {noykat}> on Wednesday January 03 2018, @08:57PM (#617345) Journal

    https://newsroom.intel.com/news/intel-responds-to-security-research-findings/ [intel.com]

    Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

    Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

    Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.

    https://www.barrons.com/articles/intel-refutes-chip-bug-inaccurate-media-reports-1515010736 [barrons.com]

    https://www.bloomberg.com/news/articles/2018-01-03/intel-says-research-showed-design-element-created-vulnerability [bloomberg.com]

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 5, Insightful) by Justin Case on Wednesday January 03 2018, @09:32PM (1 child)

      by Justin Case (4239) on Wednesday January 03 2018, @09:32PM (#617359) Journal

      Wow the spin is heavy in that one!

      Intel and other technology companies

      See? It's not just us! Other companies have been... made aware. Oh. Nevermind.

      devices that are operating as designed

      Nothing to see here. We designed this flaw, so everything's OK.

      Intel believes these exploits do not have the potential to corrupt, modify or delete data.

      In other news, it is utterly false that Martians landed on the White House lawn this morning. Oh, wait -- that wasn't ever claimed? But, you have to admit, it is still utterly false that Martians landed on the White House lawn this morning.

      No, the exploit (maybe) lets the attacker discover secrets. Then the attacker can do other badness using those secrets. What badness? Who knows? Maybe even land on the White House lawn!

      Recent reports [compound clause] are incorrect.

      This is an "if" statement with two parts separated by an "and". One part may be false, so the compound condition is false. But they want you to assume both parts are false.

      Intel is committed to product and customer security

      Yeah, so committed we allowed this to happen and never discovered, reported, or fixed it for $MANY years. The "we are committed" is standard language whenever someone gets caught with their pants down. It is non-measurable and meaningless.

      I am committed to world peace. Now, where did I leave my red button that is bigger than Trump's or North Korea's?

      • (Score: 1) by pTamok on Wednesday January 03 2018, @10:55PM

        by pTamok (3042) on Wednesday January 03 2018, @10:55PM (#617400)

        I agree that Ashes-winning amounts of spin have been used.

        The point is that a user-mode (Ring-3) program should not be able to see kernel-mode (Ring-0) data*. Exposing 'sensitive' data is basically game-over, security wise if, for example, that sensitive data is an encryption key or a password.

        There were probably exigent reasons for Intel to make this (among many) poor design choices in the history of the x86 architecture, but it is yet another excellent example of why having a hardware (or software) monoculture is a bad idea.

        Also, working as designed, does not mean the design is correct. No doubt the BSDs will need to make some changes, and if there are any, any O/S that is meant to be security assured on the x86 (or 64-bit ARM) may need to re-evaluate the correctness of their assumptions.

    • (Score: 2, Informative) by Anonymous Coward on Wednesday January 03 2018, @10:15PM (3 children)

      by Anonymous Coward on Wednesday January 03 2018, @10:15PM (#617386)

      To be fair to Intel, it is informed speculation at this point. First we have the Gruss paper: [gruss.cc]

      Prefetch instructions on Intel CPUs ignore privilege levels and access permissions. Thus, it is possible to prefetch execute-only pages, as well as inaccessible kernel memory. When running the procedure over the whole address space, we now also obtain information on all kernel pages. Note that even a process with root privileges could not obtain this information without loading a kernel module on modern operating systems.

      A good assumption here is that they're talking about the x86 ISA. Then we have Tom Lendacky's patch: [lkml.org]

      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 modewhen that access would result in a page fault.

      That says this specific issue is not the ISA and not limited to the ISA prefetch instruction which (presumably) could be patched via microcode but is limited to Intel chips. This leaves automatic prefetch as a result of branch prediction and speculative execution with the (assumed) bug being that information is available in cache despite a page table fault. It is not an unreasonable assumption for people to have made based on the available evidence. The KASLR issue is separate from this specific bug although it comes from the same batch of papers. [gruss.cc]

      • (Score: 2) by shortscreen on Thursday January 04 2018, @05:35AM (2 children)

        by shortscreen (2252) on Thursday January 04 2018, @05:35AM (#617534) Journal

        information is available in cache despite a page table fault

        How does information being in the cache become available to user code? I don't know of any way to directly read the cache or dump its contents to my own buffer. Or, once it's in the cache, does that mean attempting to read it a second time (for real) will succeed without triggering a page fault?

        • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @10:16AM

          by Anonymous Coward on Thursday January 04 2018, @10:16AM (#617604)

          How does information being in the cache become available to user code?

          If you ever bought flat pack furniture you know the answer; "some assembly required". The linked paper details side-channel timing attacks against KASLR, this in turn enables control flow hijacking and code reuse attacks. I don't think the story of the prefetch issue stops here and the mitigation patches add more 0xCR3 gadgets.

        • (Score: 2, Informative) by Anonymous Coward on Thursday January 04 2018, @01:31PM

          by Anonymous Coward on Thursday January 04 2018, @01:31PM (#617656)

          The trick is that the data is not just in the cache, it is also available in the program during speculative execution.
          So you need to execute further code that produces an effect even if the speculative execution is later canceled.
          That further code is an indirect memory load.
          Something like (very simplified!)
          if (variable_that_is_false_but_CPU_assumes_to_be_true) {
          unsigned char value = *kernel_address_pointer;
          volatile int a = huge_array[value*64];
          }

          Now you "just" have to check which part of huge_array ended up in the cache and you know what data was fetched into "value" during the speculative execution...

    • (Score: 1, Informative) by Anonymous Coward on Thursday January 04 2018, @05:16AM

      by Anonymous Coward on Thursday January 04 2018, @05:16AM (#617529)
  • (Score: 2, Informative) by Anonymous Coward on Wednesday January 03 2018, @11:15PM

    by Anonymous Coward on Wednesday January 03 2018, @11:15PM (#617405)
  • (Score: 3, Interesting) by bzipitidoo on Thursday January 04 2018, @02:51AM (1 child)

    by bzipitidoo (4388) on Thursday January 04 2018, @02:51AM (#617472) Journal

    This bug goes all the way back to the Pentium II? Makes you wonder what other bugs are out there, undiscovered.

    I have a 133Mhz Pentium based laptop that still works, but its performance is unacceptably slow on a great many tasks. Like, don't even think of trying to watch online videos with that thing. Takes 30 seconds to launch Firefox 3.5 with a blank home page. Last time I used it, a decade ago, all I did was run xterm for some old fashioned console work.

  • (Score: 3, Insightful) by Grishnakh on Thursday January 04 2018, @02:53AM (6 children)

    by Grishnakh (2831) on Thursday January 04 2018, @02:53AM (#617474)

    I wonder how much of this is due to the history of Intel processors. Unlike the S/390 and SPARC CPUs mentioned in the article, as well as other big-iron CPUs (such as DEC Alpha, and other mainframe CPUs) from days of yore where those machines were explicitly designed with the assumption that different users would be logged in simultaneously and processes would need to absolutely be protected from each other, Intel CPUs were originally designed with the assumption that you'd be running the shitty program loader called "MS-DOS" on them, then later Windows 3.1, then Windows 95, all with mindset of a single-user system where security was really an afterthought and not taken that seriously. Intel's simply grown from there, into other Unix(-like) systems, servers, etc., but they've always been hampered by their past as seen with the terrible x86 ISA.

    • (Score: 1, Informative) by Anonymous Coward on Thursday January 04 2018, @03:07AM (3 children)

      by Anonymous Coward on Thursday January 04 2018, @03:07AM (#617483)

      x86 history goes back to 8080, the cpu that ran CP/M.

      • (Score: 2) by Nerdfest on Thursday January 04 2018, @03:35AM (2 children)

        by Nerdfest (80) on Thursday January 04 2018, @03:35AM (#617493)

        4004?

        • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @03:42AM (1 child)

          by Anonymous Coward on Thursday January 04 2018, @03:42AM (#617499)

          4004 was a 4-bit processor, a incompatible and much more primitive beast.

          • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @01:47PM

            by Anonymous Coward on Thursday January 04 2018, @01:47PM (#617660)

            8086 evolved from 8080, 8080 evolved from 8008, 8008 evolved from 4004. None of these chips are binary-compatible with any of the others, but all of them were similar and designed to make it easy to port software from the earlier version. So either the 8086 was the first or the 4004 was, but definitely not the 8080.

    • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @04:16AM (1 child)

      by Anonymous Coward on Thursday January 04 2018, @04:16AM (#617510)

      Probably more to do with executing 3 instructions at a time. Introduced at the 686 level.

      The 386 was designed to have more than one user at a time. It has a built in VM for 8086 applications. It was one of the major selling points at the time (big selling points of OS/2 and Minux). ARM also had a similar set of patches. THAT could be even worse. As that thing is mostly used for embedded applications which by far out number x86 computers.

      The ROP attack method is a fairly recent technique mostly created because of locked out platforms such as the PS3 (powerpc).

      AMD kind of screwed us a bit when they came up with x64. They had a chance to clean up a bunch of cruft. They didnt.

      • (Score: 1, Insightful) by Anonymous Coward on Thursday January 04 2018, @10:21AM

        by Anonymous Coward on Thursday January 04 2018, @10:21AM (#617606)

        AMD kind of screwed us a bit when they came up with x64. They had a chance to clean up a bunch of cruft. They didnt.

        A lot of companies made 64-bit CPU's without the x86 cruft, including Intel (Itanium). None of them were successful, people (that would be developers) wanted the c86 cruft.

  • (Score: 1, Informative) by Anonymous Coward on Thursday January 04 2018, @12:10PM (1 child)

    by Anonymous Coward on Thursday January 04 2018, @12:10PM (#617629)

    Google researchers said one of the "serious security flaws", dubbed "Spectre", was found in chips made by Intel, AMD and ARM...
    http://www.bbc.com/news/technology-42561169 [bbc.com]
    According to the researchers who found the bugs, chips dating as far back as 1995 have been affected. The first reports suggested that a bug affected solely chips made by Intel, but it has since emerged that a separate flaw, Spectre, has been found in Intel, ARM and AMD chips.

    • (Score: 0) by Anonymous Coward on Thursday January 04 2018, @02:00PM

      by Anonymous Coward on Thursday January 04 2018, @02:00PM (#617666)

      Spectre is really just a whole class of exploits, though. It's like saying, well, so what if my program has a buffer overflow, lots of programs have buffer overflows. Maybe true but it doesn't count until someone finds them. The reality is that today, while there might be security flaws affecting AMD in the future, right now there are not.*

      I think the real fix for all this is to prevent processes from timing things so precisely. You can't fix the timing differences without disabling basically every performance optimization that's been done for the last 30 years, but if you can fix getting the information from a different process, then you can't exploit it.

      Sort of like how you can fix each individual buffer overflow, or you can just do bounds checking and fix them all.

      * The BPF exploit is really a kernel bug in my opinion, AMD is allowing the kernel only to read its own memory, the kernel just needs to do a better job validating the input.

(1) 2