New Intel patches promise immunity to Meltdown and Spectre attacks

The world and its dog have been following the rather scary story of the Meltdown and Spectre CPU exploits. As a quick recap, a security vulnerability in most modern CPUs allows a standard unprivileged program to extract sensitive information in memory, like passwords and encryption keys. Intel CPUs are particularly affected since the Meltdown vulnerability is apparently specific to them. The company's now issued a statement saying it's "made significant progress" in deploying software patches and firmware updates to partners that will make its chips "immune" to the exploits.

Intel says that it already has patches in place for "the majority of processor products introduced within the past five years." The company's own list of affected CPUs extends much farther back than that, so it's possible that not all systems will see a fix. The company also says that many operating system vendors, cloud service providers, device manufacturers already have their products and services all patched up.

Intel also has a word on the rumors about the scary-high performance hits of the patches for these vulnerabilities on software running on its CPUs. The CPU maker insists that the performance impact is "highly workload-dependent" and that it shouldn't be significant to the average computer user. The company also thinks that the performance drops will decrease over time as the software updates are tested and improved. Whatever the case may be, both Intel's advice and ours remains the same: patch all your systems as soon as updates are available.

Comments closed
    • NeelyCam
    • 2 years ago

    Just saw this:

    [url<]https://www.theverge.com/2018/1/9/16867068/microsoft-meltdown-spectre-security-updates-amd-pcs-issues[/url<] And this: [url<]https://www.theverge.com/2018/1/9/16868290/microsoft-meltdown-spectre-firmware-updates-pc-slowdown[/url<]

    • anotherengineer
    • 2 years ago

    Hmmm interesting reads

    [url<]https://www.techpowerup.com/240283/intel-released-coffee-lake-knowing-it-was-vulnerable-to-spectre-and-meltdown[/url<] [url<]https://www.techpowerup.com/240298/intel-braces-for-an-avalanche-of-class-action-lawsuits[/url<]

      • Klimax
      • 2 years ago

      Seems they took page out of SW vendors and simply did Day 0 update. If Intel loses it, then it might be used as vector against SW. (Especially games)

      That won’t be fun times…

    • rutra80
    • 2 years ago

    Can anyone confirm that Slither has ~half the FPS on patched Edge?

    • Rza79
    • 2 years ago

    How about the old forgotten duckling, MIPS?

    Well, MIPS is not vulnerable to Meltdown. Linux on MIPS can not leak any kernel pages — simply because MIPS does not do paging in kernel mode.

    Never understood why ARM was pushed so hard a decade ago.

    • Klimax
    • 2 years ago

    Small reminder: Meltdown might not be Intel-only! (or related vulnerability)
    [url<]https://www.realworldtech.com/forum/?threadid=173641&curpostid=173768[/url<] (About AMD) [url<]https://www.realworldtech.com/forum/?threadid=173641&curpostid=173747[/url<] (ARM won't save you either)

      • Redocbew
      • 2 years ago

      If they’re calling this one “Meltdown”, then maybe they’ll call the next variant “Slag Heap”. Seems like there’s already a number of people expecting that there will be more variants.

      • chuckula
      • 2 years ago

      Actually Meltdown is officially confirmed to affect the Cortex A75 (see the ARM section of this article: [url<]https://arstechnica.com/gadgets/2018/01/meltdown-and-spectre-heres-what-intel-apple-microsoft-others-are-doing-about-it/[/url<] ) Older ARM designs do not appear to be affected (at least right now). So Meltdown is not 100% Intel specific although Intel makes the large majority of parts that are affected by it since the A75 isn't that widespread yet.

    • dfi
    • 2 years ago

    This is why I trust Intel. Meanwhile AMD still refuses to even acknowledge that they are also affected by this.

      • mcarson09
      • 2 years ago

      Careful the AMD fanbois are stronger here. I’m honestly shocked you don’t have more downvotes.

      For the record I feel the same way.

        • thx1138r
        • 2 years ago

        You’re forgetting about the “common sense” fanbois who believe that you shouldn’t really trust any companies claims.

          • K-L-Waster
          • 2 years ago

          Sadly we’re a small minority…

      • Star Brood
      • 2 years ago

      You trust the company whose CEO sold off his shares before this announcement? [url<]http://www.businessinsider.com/intel-ceo-krzanich-sold-shares-after-company-was-informed-of-chip-flaw-2018-1[/url<] But you claim AMD "refuses to acknowledge" they are impacted by this issue even when they have actually claimed "we are not"? Sounds like a butthurt shareholder to me just farting upwind.

        • mcarson09
        • 2 years ago

        Better than trusting a company that chooses not to fund their R&D.

          • sreams
          • 2 years ago

          Yeah. Ryzen took no R&D at all. I just built one in my basement last night.

          • Redocbew
          • 2 years ago

          What does that even mean?

          Signal meet noise. A lot of noise.

      • thx1138r
      • 2 years ago

      [quote<]AMD still refuses to even acknowledge that they are also affected by this.[/quote<] Well that's simply wrong: [url<]https://www.amd.com/en/corporate/speculative-execution[/url<] While everybody agrees that AMD chips are not vulnerable to the Spectre bug. They clearly state that they are vulnerable to two variants of the Meltdown bug.

        • Klimax
        • 2 years ago

        Beware, that might not last:
        [url<]https://www.realworldtech.com/forum/?threadid=173641&curpostid=173768[/url<]

          • thx1138r
          • 2 years ago

          Yes, you already posted that link, but the point stands, Meltdown has not been demonstrated on AMD chips. And until it has all you’re doing is trying to create FUD in an attempt to try to make intel look less bad.

            • Klimax
            • 2 years ago

            FUD? Failure to understand point of that link. Second, ARM is hit too. So kindly take your fanboyish defense of AMD elsewhere.

            Also you may want to check timestamps…

            • thx1138r
            • 2 years ago

            defence of AMD?

            I don’t believe AMD or Intel, I pay more heed to the reports of independent security researchers.. The balance of which say that AMD’s analysis of the situation is more accurate at the moment. If those or other researchers change their stance then I will quickly change my mind.

            Thus you attempt at creating uncertainty about the AMD chips is indeed attempted FUD in my mind.

            • Klimax
            • 2 years ago

            Two different companies got hit by Meltdown and related vulnerabilities (Intel and ARM). Probability that AMD got so lucky that their speculative execution simply cannot be vulnerable to any Meltdown-class of attack is very low.

            And like Intel got its ass kicked by reality, AMD set its own ass up for nice kicking if there is an Meltdown lurking around. Just because some variants don’t work doesn’t mean none can work. Immunity is unfortunately not exactly provable, because of complexity of system.

            I guess we will see if AMD was that lucky or there.

            Small reminder, Section 6.4 of Meltdown paper:
            [quote<] We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. [b<]First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage.[/b<] Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. [b<]However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.[/b<] [/quote<] So beware...

        • Redocbew
        • 2 years ago

        There’s two variants of Spectre and one of Meltdown. The first time I read AMDs release I read it backwards like that also.

        However, the point remains: a wrong dude is wrong.

          • thx1138r
          • 2 years ago

          You’re right, thanks for the correction, AMD was lumping them all together.

    • Eversor
    • 2 years ago

    This list doesn’t seem right:

    – Atom Zxxx/Z2xxx is in-order (Bonnel).
    – Atom x3 (SoFIA) is mentioned but x5 and x7 are not (all Silvermont).
    – Core M starts at 14nm

    Then the naming mess continues to bite Intel (finally). Instead of saying Core ix and Core M are affected, “2nd Generation Core” can IMHO be confused with Core 2 and needlessly increases the list.

    The in-order case is either wrong or HT on the Atoms is causing issues (this has been the case since the P4 introduced it but the issue has largely been ignored)[1].

    My understanding is that anything with a shared last level cache and speculative execution would be impacted – I was expecting Core 2 to be on the list (and less so, Yonah).
    Very strange if this is not the case, as this may very well end up as a bug introduced with Nehalem due to lacking validation on Intel’s part.

    [1]http://www.daemonology.net/hyperthreading-considered-harmful/

      • the
      • 2 years ago

      If it was a Hyperthreading thing, then Itanium should be on that list as well. Poulson and Tukwila have Hyperthreading that tries to mirror the x86 implementations a bit more.

      Cross referencing some of the Atom series lists, it seems that Intel has made no clear distinction if Bonnell based designs are susceptible or not. They [i<]shouldn't[/i<] be as they're in-order but this bug has apparently hit other platforms that you think would be immune as well.

      • mczak
      • 2 years ago

      The list may very well be wrong, but I’m not sure why everybody seems to assume in-order cpus are safe.
      Every at least “somewhat fast” cpu which is properly pipelined does speculative execution based on branch prediction, and that certainly includes the original atoms. I don’t see anything which would indicate you need out-of-order execution for spectre based exploits.
      Albeit since spectre relies on being able to manipulate the branch predictor from another process, that might indeed be why the original atoms are on the list and the newer ones not. Without HT, the required context switch for manipulating the branch predictor from another process might ruin your chances of this being successful. (Albeit the spectre paper mentions just about every cpu being vulnerable to this class of attacks, including arm chips for instance, suggesting it indeed works even with context switches when the malicious code is not actually running simultaneously. I think it isn’t entirely clear at this point which cpus are really exploitable.)

      Edit: albeit actually it looks like another prerequisite of the exploit isn’t just that you can influence the branch predictor and the cpu is executing branches speculatively, but also that the cpu actually reorders loads, which isn’t going to happen on in-order cpus. So they might be safe…

        • Eversor
        • 2 years ago

        I’m a bit rusty on microarchitecture but IIRC HyperThreading ends up as a form of out of order execution, as pertains to using cache side-channel attacks.
        The CPU is putting the load on-hold while it executes another thread of instructions, which if having no dependencies on units of the first thread (as detailed in Anders Fogh’s post), will keep running and leak data the cache access being completed by the first thread.

        What is not helping anyone is Intel still hasn’t explained how the issue pertains to it’s architectures and to what exploits affect which core versions, as ARM did.

        Cortex-A8 is in-order but is still affected by Spectre exploits, despite speculative execution being more tightly connected to OoO cores, as it pertains to the exploits.
        Cortex-A8 is documented to do speculative branching and instruction fetching but, without looking at ARM’s table, I would’ve said there is no way you can leak information there.
        Looking at the architecture, it is possible the BIU is triggered by the cache miss earlier in the pipeline (the execution state is quite big) and then you can look in the shared cache with a receiver process running on another core.

        Interestingly, a cache attack quoted on the Meltdown paper mentions that attack is possible in K8 but not Piledriver cores due to the L3 being an exclusive cache. I wonder if they missed vectors of attack, like pinning the receiver thread on a module and leak through the inclusive, shared L2.

    • mtruchado
    • 2 years ago

    just look how PostgreSQL performs before and after applying the patch and you will see that the statement “it shouldn’t be significant to the average computer user.” is not accurate. Basically, I/O task performs half the way It was originally planned.

    “Average computer user” means the same as “average daily phone using”, both are saying nothing. My average computer user is related to databases, application servers, web services, compiling and such stuff. So is the average computer user for my colleagues, for others is gaming, for other is video editing… please, let’s be more concise with these kind of sentences.

      • tipoo
      • 2 years ago

      The average user is more in the 2.5% hit to web performance (so, ‘shouldn’t be significant to the average computer user.’), but yeah, the impact to SQL, compiles, random db reads etc, will be much more brutal.

        • the
        • 2 years ago

        Red Hat has a [url=https://access.redhat.com/articles/3307751<]page up[/url<] regarding performance impacts they're estimating for select workloads. Not as dire as initial tests were point to but still pretty bad for the SQL folks.

      • Kretschmer
      • 2 years ago

      “Average Computer User” means “most common tasks across the population” – browsing, social media, email, streaming video.

      If you feel the need to argue the definition, you’re not an average user.

      • K-L-Waster
      • 2 years ago

      The “average user” has never heard of PostgreSQL…

    • blastdoor
    • 2 years ago

    [quote<]it shouldn't be significant to the average computer user[/quote<] Is this because the average computer user hasn't been doing anything that is CPU-constrained for at least 10 years? So even if they did take a 30% hit, they wouldn't notice?

      • Redocbew
      • 2 years ago

      That’s how I’ve been reading it so far. As many people here have commented already, those most affected by Meltdown aren’t likely to be the “average computer user” anyway, but I guess we’ll have to wait for more testing before we know for sure.

        • blastdoor
        • 2 years ago

        There is an important distinction, though, between “server workloads” and “workstation workloads.” I run programs in R (https://cran.r-project.org) that can take hours or even days, but that’s not a “server workload”. Will I be affected? It’s hard to tell, because the only things I see referenced are the experiences of the “average user”, games (which are often GPU-constrained anyway), and server stuff (virtual machines).

        For people who actually buy a high-end desktop because they need it to do work, it’s not at all clear what the implications of this are. [edit — but maybe that makes sense, because the dirty little secret in this industry, which isn’t really a secret I guess, is that people who need high-end desktops to do actual work are a tiny, tiny minority]

          • Redocbew
          • 2 years ago

          My understanding is that the performance implications of Meltdown center around system calls. If your apps spend most of their time crunching away in user space without opening a bunch of different files, or otherwise requesting things from the OS on a frequent basis then you might not be heavily impacted. It’s a good question though, which I’d be interested in also. I used to do a lot of video encoding, which would put me in a similar situation should those kind of projects pop up again.

    • Topinio
    • 2 years ago

    Intel says that it already has patches in place for “the majority of processor products introduced within the past five years.”

    I’m typing this on a system I ordered parts for 7 years ago this week, Intel Core i5-2500K on Intel DH67DG motherboard.

    Intel choosing to not support this system will be remembered, and I’d hope I’m unlikely to be in the minority view there.

      • smilingcrow
      • 2 years ago

      Intel no longer make motherboards and it is 7 years old so knock yourself out.

        • Topinio
        • 2 years ago

        My point is that under 7 years, even 10, isn’t an unreasonable length of time for a computer – so while I can’t expect driver updates, I think that I should be able to expect security ones, particularly when the part is on the affected list.

          • adisor19
          • 2 years ago

          Buy a Mac. Mac Mini 2010 still getting updates and is able to run High Sierra.

          Adi

            • xeridea
            • 2 years ago

            Apple generally refuses to even acknowledge any security flaws, no matter how big, even exist. They usually sloth around hoping people forget, before being forced to admit anything and begrudgingly patch it. They cant ruin the whole RDF, now can they?

            • cegras
            • 2 years ago

            What do you ascribe this behaviour to? From all recent news, Apple is on top of security for their products.

          • smilingcrow
          • 2 years ago

          Do you also expect to get firmware security updates for a 7 year old phone or tablet?
          That is 4 years outside the typical warranty period for a motherboard so any updates are a bonus.
          When you consider that Intel ceased production about 4 years ago all those boards should be out of warranty by now.
          As I said, they don’t have the facilities any more so adding all that together and you just bet on the wrong horse as did people who bought Abit boards.

      • just brew it!
      • 2 years ago

      Meltdown is more of a concern for hosting providers (not desktop users), and in any case the patch for that will likely come from your OS vendor (in the form of a PTI patch), not Intel.

      I’m skeptical of the existence of a simple and effective mitigation for Spectre. Suggest you use Chrome, and enable the experimental site-per-process feature; this will at least limit your exposure. And again, the actual fix for this one will come from software vendors (not Intel), as the biggest attack vector appears to be JavaScript; so it is up to the browser vendors to defend against this one.

      Any advice Intel has given the OS and browser vendors for later CPUs is probably applicable to the i5-2500K as well.

      I think your ire is a little misplaced.

      (And this comes from someone who has bought AMD processors almost exclusively for nearly 2 decades, so I’m about as far from an Intel fanboy as you can get. I’m typing this on an FX-8350 on an Asus M5A99FX Pro R2.0!)

        • Topinio
        • 2 years ago

        Maybe, but it seems there’s a firmware fix for part of this and I think it should be made available to all affected systems.

        I don’t expect support in general, but this would be a good time for Intel to go further than bare minimum.

        (Edit for autocorrect phone typo)

          • just brew it!
          • 2 years ago

          I don’t think they’ll have much luck getting all the other motherboard vendors to roll out BIOS updates for 5 year old motherboards though…

      • thedosbox
      • 2 years ago

      How long was the warranty on that board? And what other manufacturers offer a seven year warranty?

      *crickets*

        • Topinio
        • 2 years ago

        This is a serious flaw, and it’s very rare that such happen. Now would be an excellent time for Intel to go beyond the bare minimum contractual requirements, no?

      • DancinJack
      • 2 years ago

      It’s never enough is it? If they provided updates for 11 years someone would ask for 15. Just the way it goes.

        • NovusBogus
        • 2 years ago

        I for one am sorely disappointed that Ford no longer sells replacement parts for my Model T.

          • Peffse
          • 2 years ago

          Might want to check if Ford owes you some safer parts.
          [url<]https://www.recalls.gov/nhtsa.html[/url<]

      • Eversor
      • 2 years ago

      You, and many owners of motherboards of that era of UEFI, have not received updates for really bad UEFI exploits related to SMM.

      Then there is the ME exploit just recently. Only expensive and recent hardware only got fixes; though I did look at HP’s page and they were patching a lot of machines (the others, much, much less).

      I remember the UEFI exploit going 90%+ unpatched on the most sold motherboards from the big four – Gigabyte and ASUS had some BIOS for Z chipsets and others were similar.

      • chucko
      • 2 years ago

      I have a similar system in my fleet. It’s an Intel i5-2500K on an Intel DH67BL motherboard, running Windows 8.1 Pro. I was able to download and manually install the Microsoft patch(es) earlier today. Everything seemed to install properly.

      I’m curious as to why you don’t think this product is supported?

        • Kretschmer
        • 2 years ago

        Because he wants to complain that a fix didn’t come directly from Intel.

    • gcrosier
    • 2 years ago

    Your link to Intel’s affected CPUs goes to an article about a monitor? Just FYI.

      • Topinio
      • 2 years ago

      Here: [url<]https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088[/url<] Everything since Nehalem. List is marked as "Intel may modify this list at a later time", possibly because earlier systems are as-yet untested.

        • nanoflower
        • 2 years ago

        Your link wouldn’t work for me due a lack of language specification.

        [url<]https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr[/url<] Intel® Core™ i3 processor (45nm and 32nm) Intel® Core™ i5 processor (45nm and 32nm) Intel® Core™ i7 processor (45nm and 32nm) Intel® Core™ M processor family (45nm and 32nm) 2nd generation Intel® Core™ processors 3rd generation Intel® Core™ processors 4th generation Intel® Core™ processors 5th generation Intel® Core™ processors 6th generation Intel® Core™ processors 7th generation Intel® Core™ processors 8th generation Intel® Core™ processors Intel® Core™ X-series Processor Family for Intel® X99 platforms Intel® Core™ X-series Processor Family for Intel® X299 platforms Intel® Xeon® processor 3400 series Intel® Xeon® processor 3600 series Intel® Xeon® processor 5500 series Intel® Xeon® processor 5600 series Intel® Xeon® processor 6500 series Intel® Xeon® processor 7500 series Intel® Xeon® Processor E3 Family Intel® Xeon® Processor E3 v2 Family Intel® Xeon® Processor E3 v3 Family Intel® Xeon® Processor E3 v4 Family Intel® Xeon® Processor E3 v5 Family Intel® Xeon® Processor E3 v6 Family Intel® Xeon® Processor E5 Family Intel® Xeon® Processor E5 v2 Family Intel® Xeon® Processor E5 v3 Family Intel® Xeon® Processor E5 v4 Family Intel® Xeon® Processor E7 Family Intel® Xeon® Processor E7 v2 Family Intel® Xeon® Processor E7 v3 Family Intel® Xeon® Processor E7 v4 Family Intel® Xeon® Processor Scalable Family Intel® Xeon Phi™ Processor 3200, 5200, 7200 Series Intel® Atom™ Processor C Series Intel® Atom™ Processor E Series Intel® Atom™ Processor A Series Intel® Atom™ Processor x3 Series Intel® Atom™ Processor Z Series Intel® Celeron® Processor J Series Intel® Celeron® Processor N Series Intel® Pentium® Processor J Series Intel® Pentium® Processor N Series

    • JosiahBradley
    • 2 years ago

    Users have posted benchmarks showing the slow downs pre and post patch, why is Intel eating its own foot so hard?

      • chuckula
      • 2 years ago

      Phoronix has posted plenty of test results so far. In general there is an observed slowdown in virtualization and server workloads but it’s not living up to the hype outside of synthetic microbenchmarks.

      [url<]https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm&num=1[/url<] Bear in mind this is with the first-generation of KPTI patches that aren't particularly optimized and the "ooh wow" performance numbers are all pretty much in the synthetic benchmark realm. To put it in perspective, go look at some of those synthetic benchmarks between different kernel versions and you'll see deviations in performance too. Edit: And is if Larabel had read my mind, here are a bunch of tests of various Linux kernel versions where the variations in app performance between kernel versions are bigger than the impact of KPTI being on or off: [url<]https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=1[/url<] Games show basically zero performance difference: [url<]https://www.phoronix.com/scan.php?page=article&item=nvidia-linux-kpti&num=1[/url<]

        • JosiahBradley
        • 2 years ago

        We run nearly a thousand VMs many Linux based and hosted. This is a massive blow to our data center, which in turn affects our end users the average Joe and Jane. I’m not caring about gaming right now I’m caring about 50% IO cuts and poor (X)SQL performance here.

          • chuckula
          • 2 years ago

          OK, so where are your quantified benchmarks showing this 50% performance drop?

          I’m asking because [url=https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html<]Google doesn't seem to see any issues with its cloud platform[/url<] and I'm pretty sure they're running more than 1,000 VMs: [quote<]There has been speculation that the deployment of KPTI causes significant performance slowdowns. Performance can vary, as the impact of the KPTI mitigations depends on the rate of system calls made by an application. On most of our workloads, including our cloud infrastructure, we see negligible impact on performance. In our own testing, we have found that microbenchmarks can show an exaggerated impact. Of course, Google recommends thorough testing in your environment before deployment; we cannot guarantee any particular performance or operational impact.[/quote<]

            • Puiucs
            • 2 years ago

            All you have to do is look at the Amazon forums concerning AWS. You’ll see many people posting about huge hits to their VMs and workloads with more than 30% extra CPU usage. Coupled with IO performance drops, it forces many people to upgrade their servers to the more expensive versions.

            Game companies like CCP and Epic also posted CPU usage graphs that show big CPU usage increases for certain workloads. that go beyond 2x CPU loads compared to before the patches.

        • nanoflower
        • 2 years ago

        The same was seen by Hardware Unboxed on Youtube who tested a number of games and saw no noticeable difference in performance before and after the patch. [url<]https://www.youtube.com/watch?v=_qZksorJAuY&t=0s[/url<]

      • IGTrading
      • 2 years ago

      In some situations, server real world applications, we seem to be having catastrophic results :

      [url<]https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update[/url<]

    • mudcore
    • 2 years ago

    Hm. I’m highly skeptical about the claims of immunity regarding Spectre. That goes for both Intel here and what AMD states about their processors.

    Also… I think the industry needs to come up with better language when communicating issues that impact primarily server workloads to normal users. It comes down to the fact that many of the systems that do run workloads that are impacted are for services average computer users use. The “average computer user” local PC probably sticks almost entirely to very light loads that don’t stress modern systems at all beyond video playback in specific instances. But they all use services that are hosted remotely that may have workloads that are impacted and the costs there will ultimately be moved on to the end user. Be it the computing power ‘lost’ or the human hours it costs to address these issues, develop the software mitigations Intel describes, etc.

    I recognize the difficulties in capturing the impact, how to communicate it without creating panic bubbles, etc. But I also think what these companies do now which is effectively tell people to not care isn’t the right path either. It especially isn’t in a industry that near universally encourages and makes people reliant on remotely hosted services.

      • just brew it!
      • 2 years ago

      [quote<]Hm. I'm highly skeptical about the claims of immunity regarding Spectre. That goes for both Intel here and what AMD states about their processors.[/quote<] Same here. At least Spectre is an in-process sandbox data leak (and not a process-OS or process-process leak); given this, Chrome's new "site-per-process" feature sounds like it may limit the potential damage. Further mitigation should be possible in the JavaScript implementation (at the cost of web browser performance).

        • blastdoor
        • 2 years ago

        Of all the CPU cycles devoted to JavaScript, I wonder what fraction is ad-related. >50% ? > 80%? > 90%?

        Maybe if we really added up the benefits and costs, we would conclude that everyone except advertisers are better off without scripting in browsers…

          • Redocbew
          • 2 years ago

          It’s probably quite a bit, but I’m not sure it’d be the majority. Even without considering security there’s a lot of things to dislike about Javascript, but the cat’s out of the bag on that one.
          Googling released Dart several years ago intending for it to be a replacement for Javascript at least in part, and it promptly went nowhere. If Google can’t uproot Javascript, then it probably won’t be any easier for anyone else.

      • mcarson09
      • 2 years ago

      It’s not the first time AMD would lie about something. I wish we had through benchmarks on this and not just some Linux benchmarks. They should be tested across multi platforms.

    • chuckula
    • 2 years ago

    [url=https://www.youtube.com/watch?v=xWBFWw3XubQ<]You made me. Promises Promises. You knew you'd never keep[/url<]

      • mcarson09
      • 2 years ago

      Don’t start ruining good songs with your taint.

        • derFunkenstein
        • 2 years ago

        chuckula is a Grey Warden, who consumed the Darkspawn blood and [url=https://www.youtube.com/watch?v=6bBN2j3sG00<]mastered his taint[/url<].

          • K-L-Waster
          • 2 years ago

          …along with Alistair’s mastery of cheesy jokes….

Pin It on Pinterest

Share This