Slashdot Mirror


Intel Says 'Partitions' in New Chips Will Correct the Design Flaw that Created Spectre and Meltdown (geekwire.com)

Intel said on Thursday it is introducing hardware protections against the Spectre CPU flaw that was discovered last year. From a report: Starting with the Cascade Lake version of its Xeon server processors later this year, Intel will incorporate "protective walls" in its hardware that prevent malicious hackers from using speculative execution techniques to steal private information from the secure part of the processor. These fixes will also ship with the PC version of the Cascade Lake chips, but the tech industry has been much more concerned about the effect of these design flaws on server processors running in data centers and cloud vendors.

The new fixes allow Intel to still benefit from the performance advantages of speculative execution -- in which a processor guesses which upcoming instructions it will need to execute in order to speed things up -- without the security risks. The hardware changes address Variants 2 and 3 of the Spectre and Meltdown issues first disclosed in early January, and software fixes should continue to address Variant 1, Intel said.

68 comments

  1. Obligatory: Intel CPU Backdoor Report (Jan 1 2018) by Anonymous Coward · · Score: 2, Informative

    Change log:
    2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)

    Intel CPU Backdoor Report
    The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

    What we know about Intel CPU backdoors so far:

    TL;DR version

    Your Intel CPU and Chipset is running a backdoor as we speak.

    The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

    30C3 Intel ME live hack:
    [Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
    @21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.

    [Quotes] Vortrag:
    "the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".

    "We can permanently monitor the keyboard buffer on both operating system targets."

    Decoding Intel backdoors:
    The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

    If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

    Backdoor removal:
    The backdoor firmware can be removed by following this guide using the me_cleaner script.
    Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

    2017 Dec Update:
    Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.

    Useful links (Added 2018 Jan 1):
    Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
    me_cleaner: Set HAP AltMeDisable bit with -S option
    Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
    EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
    Sakaki's EFI Install Guide/Disabling the Intel Management Engine
    Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
    CVE-2017-5689: An unprivileged network attacker could ga

  2. In related news ... by fahrbot-bot · · Score: 5, Funny

    Intel will incorporate "protective walls" in its hardware ...

    Big, beautiful walls and Intel will get AMD to pay for them. :-)

    --
    It must have been something you assimilated. . . .
    1. Re:In related news ... by Anonymous Coward · · Score: 3, Funny

      Intel will incorporate "protective walls" in its hardware ...

      Big, beautiful walls and Intel will get AMD to pay for them. :-)

      By shorting AMD stock?

    2. Re:In related news ... by Anonymous Coward · · Score: 0

      Till some mountain climbing nerd comes along and ruins the CPU party.

      https://www.esquire.com/lifestyle/a19424416/ed-viesturs-professional-mountain-climber-trump-wall/

    3. Re:In related news ... by Anonymous Coward · · Score: 0

      Big, beautiful walls and Intel will get AMD to pay for them.

      #MIGA

    4. Re:In related news ... by Anonymous Coward · · Score: 0

      Can't spectres go through walls?

    5. Re:In related news ... by Anonymous Coward · · Score: 0

      To be fair, the walls are already there. They will just be improved upon so they now work as intended.

  3. Aren't we all supposed to be dead by now? by Seven+Spirals · · Score: 1, Insightful

    Where are the weaponized exploits that were going to sweep the internet and the zillion-unpatched-windows hordes? *YAWN* Again, I've gotta kick the news habit. What a hyperventilating waste of time this has been watching IT news and vendors nearly faint.

    1. Re:Aren't we all supposed to be dead by now? by MachineShedFred · · Score: 1

      While I agree, these flaws are in hardware that is staying in use for longer and longer with each cycle (because the performance is still adequate enough that people don't want to buy a new PC). That gives people plenty of time to find ways to exploit the flaw, and still have many vulnerable systems out there.

      Software vulnerabilities can be patched up within days. This one will be years before there is "herd immunity".

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    2. Re:Aren't we all supposed to be dead by now? by Anonymous Coward · · Score: 0

      Meltdown and Spectre aren't nearly as dangerous as all of the paranoid, tinfoil hat wearers and shills claimed. We've been using CPUs with the so-called "flaw" for over two decades and not a *single* incident of them being exploited has ever occurred. It's unlikely that just because it went public that would change a thing.

      I'm still running unpatched from them and I have zero worries. All of my security that has already been in place prevents anyone from exploiting them, even if they could (which already isn't easy ).

    3. Re:Aren't we all supposed to be dead by now? by Anonymous Coward · · Score: 0

      Meltdown and Spectre aren't nearly as dangerous as all of the paranoid, tinfoil hat wearers and shills claimed. We've been using CPUs with the so-called "flaw" for over two decades and not a *single* incident of them being exploited, that you know of, has ever occurred.

      FTFY

    4. Re:Aren't we all supposed to be dead by now? by sound+vision · · Score: 1

      Where are they? All over the place, hidden, and attacking high-value targets - exactly as they are designed to do.
      What they aren't designed to do, is announce their presence on Slashdot. Doubtlessly, they will be reported here - after things called investigations are completed, by people called researchers, organized into things called agencies.
      Meanwhile, we'll have these other people called 'shills' continually trying to downplay this vulnerability until Intel finally has dumped its whole stock of bugged chips.
      If you haven't been paying attention - the security researchers left Slashdot around 15 years ago, and the shills have been gradually filtering into their place since then.

  4. Intel's stock is worth $0 and should be bankrupt by Anonymous Coward · · Score: 1

    Whats good for AMD is good for Intel eh CTS labs?

  5. Failed at that before by DrYak · · Score: 4, Insightful

    Intel has already failed at exactly that before :

    IntelME was supposed to be exactly that: a separated isolated ARC core in the chipset, that was used to handle administrative tasks even if the main x86 CPU was shutdown (IntelAMT - Intel own NIH syndrom "lights out management" vaguely similar to IPMI). Got further repurposed for some trusted security tasks (TPM), got further repurposed for DRM related task, used also for critical steps to bring the hardware up.

    And was the target of attacks and exploits last summer. Attacks that thus work EVEN when the main x86 CPU is turned off (remembre, before the overarching list of roles, it began as an IPMI-like solution). To the point that vendors like DELL started offering new BIOS/UEFI firmware, in which the Intel ME code was stripped to the bare strict minimum for just the "bring hardware up" part.

    But I'm sure *this time around* the walled secure CPU core that Intel promise will be flawless and never exploited~~

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:Failed at that before by Anonymous Coward · · Score: 0

      Spectre and Meltdown were discovered and disclosed in order to boost the slumping PC sales. And it will work. Now everyone must buy these shiny new chips and new compatible motherboards to get the performance level they had before (and the security level they thought they had but never did).

      In another few years, the flaws in these walls will be disclosed, so the cycle can start again.

    2. Re:Failed at that before by Anonymous Coward · · Score: 0

      I'm glad Intel is making another go at a fix inside the CPU. Software fixes can mitigate the problem but if malware can get onto the system, escalation/exfiltration attacks are still possible.

      How convenient that all current CPUs will have less complete protections. For thorough protection everyone will have to buy new CPUs. :-(

    3. Re:Failed at that before by Anonymous Coward · · Score: 0

      "discovered and disclose"

      that's a funny way to spell "purposefully put there"...

      The rest of your comment is bang on though....

      "in order to boost the slumping PC sales. And it will work."

  6. I smell a lawsuit... by Anonymous Coward · · Score: 0

    Doesn't it take years to design and fabricate chips? And yet, the fix for this latest round of problems is already to be found in the next generation of processors to be released later this year. Almost as if they knew the flaws were coming...

    1. Re:I smell a lawsuit... by Anonymous Coward · · Score: 3, Informative

      No, these are rather small modifications to existing designs: moving protection checks earlier (for meltdown) to prevent speculative execution past a guaranteed exception is not a complete redesign.
      The protection bits are in the TLB entry, that you need to look up for address translation anyway, and then they may be checked in parallel with the cache access. Compared to looking up the tags for an 8-way (or 4, can't remember) cache access, checking the protection is simple.
      Recent chips have 57 virtual address bits of which only the 12 lower go without translation, the TLB is at least 4 way set associative, so this means that you need 4 45 bit comparators to select the TLB entry. Once translated, the L1 cache lines are 64 or 128 bytes on a physical address range of 46 bits, so this means that the cache tags are 39 or 40 bit wide (some AMD CPUs even allow a larger physical address space).
      Therefore, for the address translation and cache tags matching, you end up with at least 8 comparators about 40 bits wide each, more if the associativity is higher.
      Well, the protection bits in the TLB and the current privilege levels altogether are less then 8 bits (2 for the current privilege level, 3 or 4 for protection in the TLB entry).
      Completely negligible in terms of silicon area. Of course the logic has to be able to say: stop here, but it already needs to take into account the case of a TLB miss, and of a cache miss. It's probably not that hard to change the logic to treat a protection violation as a TLB miss, except that all that logic in Intel's core dates back to the PentiumPro...

  7. Intel Management Engine by kjhambrick · · Score: 2

    Please, please please Intel, provide a mechanism to COMPLETELY disable the IME BackDoor in your CPUs ( https://en.wikipedia.org/wiki/Intel_Management_Engine/ )

    1. Re:Intel Management Engine by ArchieBunker · · Score: 1

      AMD has the exact same thing so don't hold your hopes up.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    2. Re:Intel Management Engine by Anonymous Coward · · Score: 0

      Only the State obtains its revenue by coercion.

      Demonstrably FALSE. I work for an organization that gets most of it's revenue by coercion - and it's NOT the government. But I guess you Austrians aren't real big on empirical evidence...

    3. Re:Intel Management Engine by sexconker · · Score: 4, Funny

      You work for Oracle?

    4. Re:Intel Management Engine by Anonymous Coward · · Score: 0

      The unbreakable cohesion of the answer with the parent post suggests that. It must be a product of an engineered system of Slashdot posts.

    5. Re:Intel Management Engine by Anonymous Coward · · Score: 0

      The backdoor is not in the CPU. Buy a cpu, make a circuit board around it WITHOUT the common 'chipset'. No management engine then, only the x86 processor. And whatever you surround it with.

    6. Re:Intel Management Engine by DamnOregonian · · Score: 1

      Having just recently gotten my feet wet with Oracle SQL Server for a new billing platform (that was promptly gotten rid of)

      Spot fucking on.

  8. One problem by Anonymous Coward · · Score: 0

    You're assuming Intel has any say in it.

  9. How about more than protective walls? by ctilsie242 · · Score: 4, Interesting

    AMD has its bugs, but one new feature that they have implemented is RAM encryption. This way, one VM has no way of obtaining content from another VM's RAM space, should a leak be possible. Why not be proactive in dealing with virtualization and keeping stuff separate, perhaps adding some pipeline randomization to foil side channel attacks?

    Intel knows what they are doing. Might as well be ahead of the curve and add some useful security features.

    1. Re:How about more than protective walls? by Anonymous Coward · · Score: 0

      Unless they find some way to access the protected memory containing the encryption keys...

    2. Re:How about more than protective walls? by BronsCon · · Score: 1

      So just encr.....oh.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
    3. Re:How about more than protective walls? by Anonymous Coward · · Score: 0

      This way, one VM has no way of obtaining content from another VM's RAM space, should a leak be possible.

      That really doesn't work. A lot of the cache timing attacks don't work by directly leaking information. Instead, the work by leaking patterns of information. Think of it like the following. For a while it was standard to redact information by using a blur filter on it. There's no way to reverse a blur filter, right, so the information is secure? Except if I have a good idea what the font is, I can just take a variety of possible words, blur them, and then compare the results with what you have. Something similar happens with timing attacks and having an idea of the algorithm used. Indirectly you can find the key in a reasonable (like a day) space of time.

      Why not be proactive in dealing with virtualization and keeping stuff separate, perhaps adding some pipeline randomization to foil side channel attacks?

      The problem with this is that add randomized time doesn't really fix things. If you and a stall up to 30ms random stall, you end up just have to run the test test several times and average out the stall to 15ms. So long as the gap between possible results is distinctly over 15ms, then you can differentiate the two. The only safe thing to do is make all executions take the same amount of time. At that point, you've slowed the system to the slowest execution time, which obviously defeats the purpose of things like caching.

  10. call me crazy by Anonymous Coward · · Score: 1

    what's wrong with "check for permissions in the pipeline before doing a speculative memory access"

    1. Re:call me crazy by iggymanz · · Score: 1

      that's not how these vulnerabilities work. each process is only allowed to access its allowed memory. the bugs are from detectable side effects in caches and timings of operations

    2. Re:call me crazy by wonkey_monkey · · Score: 1

      Isn't that exactly how it works? The processor starts working on a code path which may or may not end up being taken. While doing so, that code is not subject to the usual checks The checks only come into force once the path is taken.

      --
      systemd is Roko's Basilisk.
    3. Re:call me crazy by Anonymous Coward · · Score: 0

      Meltdown is about bypassing page table permissions, allowing speculative memory access to regions that are then checked for later in the pipeline before retiring the instruction. Unfortunately the cache isn't rolled back.

      https://en.wikipedia.org/wiki/...

      the current mitigations are lamer than moving the permissions check earlier in the pipeline

    4. Re:call me crazy by Anonymous Coward · · Score: 0

      That's exactly what AMD does, and their processors are completely immune to meltdown, whatever the FUD Intel is trying to spread.

    5. Re:call me crazy by Anonymous Coward · · Score: 0

      The meltdown mitigation really is the nuclear option, but the flaw in Intel's pipeline design (checking the permissions so late that they are beyond the point of no return from an attacker point of view) leaves no other options.

    6. Re:call me crazy by iggymanz · · Score: 1

      no. even the path that isn't eventually taken has the proper restrictions on memory access. The issue are "clues" left behind that other processes might snoop with certain weird and extraordinary measures.

    7. Re:call me crazy by wonkey_monkey · · Score: 1

      But... that's exactly how it works.

      http://www.i-programmer.info/n...

      Speculatively, a byte (for example) is fetched from restricted memory. Under normal execution, this would fail with an exception. But under speculative execution, this byte is returned, and then it's used as index to access unrestricted memory - which caches that position in unrestricted memory.

      If the speculatively executed section had proper restrictions, it wouldn't have been able to access that restricted memory at all, much less use the result to access an indexed location in unrestricted memory and cache it.

      --
      systemd is Roko's Basilisk.
  11. Oh great by DontBeAMoran · · Score: 4, Funny

    Partitions inside Intel CPUs? How often will we have to re-format the damn things?

    --
    #DeleteFacebook
    1. Re:Oh great by Anonymous Coward · · Score: 0

      Just once. But they'll defrag every time you power up the processor!

    2. Re:Oh great by diesel66 · · Score: 1

      What the heck, it's more billable hours!

      --



      eleven plus two / twelve plus one
  12. Re:WTF IS WRONG WITH /.? by Anonymous Coward · · Score: 0

    The problem is they already did fire their IT department. Slashdot is run by corporate whores and a single Perl script now.

  13. Simple by Anonymous Coward · · Score: 0

    NSA exploits won't work and Intel won't get a 5% benchmark advantage

  14. Just fix what you already have by Anonymous Coward · · Score: 0

    "We have redesigned parts of the processor to introduce new levels of protection through partitioning that will protect against both Variants 2 and 3."
    Hopefully the new level is just making what is already there work.

    The ring system is already in the ISA. That allows the s/w to tell the h/w what is ok and not.
    The problem is that the specex h/w does not fully do what it is told.
    (It runs memory cycles outside of what is ok, and then permits code to use the results, and then doesn't fully negate the side effects of this code.)
    Instead of adding yet another feature to the ISA, hopefully they are just tweaking what already almost works.
    (Probably by preventing code from using the result?)
    This seems least likely to add another bug.

  15. I want storage and virtualization benchsmarks by aliquis · · Score: 1

    Not between Intel before and after the patches but Intel after against Ryzen and ThreadRipper now/after.

    Sure I know Intel perform worse with an SSD now and possibly even worse with virtualization but can I please get to see how Ryzen perform with it too?

  16. Re:WTF IS WRONG WITH /.? by Anonymous Coward · · Score: 0

    Sounds like they hired the fired Equifax I.T. stool samples.

  17. In other words, a cache nerf. by Anonymous Coward · · Score: 0

    Maybe they'll dedicate more floorspace, therefore room, for all levels of CPU cache; and with floorspace maybe there's now 5 clocks for a L1d hit instead of 4. Consumers: boned. Maybe not as boned as with the software fix, but boned nonetheless.

  18. partition? by Anonymous Coward · · Score: 0

    So intel is hiding more unknown suspect shit in their chips?

    great. thanks. but i didn't need MORE reasons not to buy intel.

  19. Won't fix your 'AMD' problem by Khyber · · Score: 4, Interesting

    While you went about paying a company to diss AMD, I checked CTS' report, found out one of my intel systems uses one of the mentioned vulnerable chipsets, the ASM1142, for its USB 3.1 controller.

    I bet that the PoC exploit would work on the intel platform right out of the box, if the CTS code isn't full of shit.

    Gimme a copy so I can test it out.

    --
    Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
  20. The WRONG way to process data privilege by Anonymous Coward · · Score: 0

    Intel Israel created the current 'core' design by crossing the Pentium 3 with the Athlon 64 (legal cos Intel and AMD have cross patent agreements- AMD based Bulldozer on Netburst, would you believe). But the jews stripped out all low level privilege data tests to ensure Mossad and the NSA could always run user code at any elevated privilege level on any Intel CPU. A useful side effect was Intel chips would then run faster per clock and clock faster cos of the simpler memory logic.

    AMD's Bulldozer was so slow because of the cross module memory tests to ensure no thread could access data from another thread- the logc completely missing in all post-Netburst Intel chips. Ryzen got vastly faster cos AMD employed a designer who knew proper optimal ways of doing the correct privilege tests in hardware.

    When Intel talks of internal DOMAINS or PARTITIONS within the CPU, it is refering to software OS methods that Intel has used since the days of Netburst. These are dealt with with the memory management/paging hardware are are the EXACT reason Intel CPUs are vulnerable to privilege escalation exploits.

    A modern simultaneous mutli-threading CPU has data (like your variable 'x') potentially stored in one of HUNDREDS of different types of RAM location. Caches (l-2, l-1, l-0, l-1, l2, l3), translation buffers, remapped registers, data in flow registers, etc etc etc. And each has to be coded with a privilege value that is tested correctly at each memory interaction to avoid exploits. Ryzen (from AMD) has this logic. Intel has removed ALL privilege value logic from its CPUs since Netburst.

    Think of a chest with a lock. an AMD thread holds a 'key' that must be inserted into the 'lock' to extract any data the thread needs. Intel data 'chests' have 'labels' but no locks. Any Intel thread can open any chest and look inside. The idea of 'domains' or 'partitions' is that you tell a thread not to do so, but it is still free to do so if it wishes.

    Intel Israel created a broken design by design. And it would take Intel at least FOUR years to come up with a correct, ryzen like design, build and deploy it.

  21. We did this in the mainframe days by davecb · · Score: 4, Interesting

    We called it "mandatory security levels and categories" (eg, Dockmaster.mil), and then reinvented them for minis (eg, Trusted Solaris) and micros (eg, SELinux), and now Intel is doing the category part in hardware, just like Multics. Methinks they're a tiny bit behind the times...

    --
    davecb@spamcop.net
    1. Re:We did this in the mainframe days by AHuxley · · Score: 1

      Think of the profit.
      An expensive new chip security to look after every CPU.
      The new generations of OS won't install on any product that does not have the new "security" chips.
      Want to run that app, game, business software? Upgrade all the hardware too. It's for security.
      12 months later its time to buy a brand new motherboard with the next gen security CPU.
      No new OS update unless the new supported chip is found.

      --
      Domestic spying is now "Benign Information Gathering"
  22. Intel FUD working by bongey · · Score: 2

    Spectre and Meltdown being mixed constantly such to always drag AMD and ARM along with their much worse Meltdown bug. Complete nonsense Spectre and Meltdown are always mention together.

  23. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    Hi, I'm one of the folks with mod points that hit you for a -1.

    No, it's not because you have secret insight and are being silenced by 'the Man'. You aren't an oppressed revolutionary struggling to help us understand the danger we are all in. It's because you are a spammy crank.

    Further down the thread, I gave someone a +1 for mentioning the problems with Intel's ME. But they related it to the topic at hand and didn't cut and paste their favourite rant. I skipped the first time you posted this. It was clearly crap, but if you'd have stopped at once, then I'd have left it alone. It was your second post where you've promised to cross-post this to other threads that made me decide to a) find another couple of these and give them a down mod and b) tell you that you're doing more harm than good.

    Content doesn't trump method. Your method deserves a -1 and if you think that you're getting a -1 because of your content, you're clinging to a delusion of persecution to make yourself feel special. Grow the fuck up.

  24. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    It's because you are a spammy crank.

    Only because you're a Intel fanboi.

    Further down the thread, I gave someone a +1 for mentioning the problems with Intel's ME. But they related it to the topic at hand and didn't cut and paste their favourite rant. I skipped the first time you posted this. It was clearly crap, but if you'd have stopped at once, then I'd have left it alone.

    Who gives a shit. This was never about you.

    Content doesn't trump method. Your method deserves a -1 and if you think that you're getting a -1 because of your content, you're clinging to a delusion of persecution to make yourself feel special. Grow the fuck up.

    This never had anything to do with me.

    The report has gotten +5 dozens of times on Slashdot.

    Referenced in numerous blog posts.

    Referenced as "Work of art" on twitter by other security professionals.

    You're just some idiot with mod point trying to feel special.

    Now fuck off while I post it on more threads.

  25. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    It was your second post where you've promised to cross-post this to other threads that made me decide to a) find another couple of these and give them a down mod and b) tell you that you're doing more harm than good.

    The first post of this thread is now back to 0 from -1:
    https://hardware.slashdot.org/...

    Clearly your opinion does not matter.

    This is about spreading the word, not you, so fuck off.

  26. LOL by Anonymous Coward · · Score: 0

    Millions of computers are infected with Intel's backdoor, millions of users are still unaware, and some random AC with mod point thinks everything is about being "Special" and him being some kind of opinion leader.

    Like the simple fact that more people need to be aware of what "Intel inside" really means totally escapes him.

    Little shit brain AC can't think beyond his little opinion.

    Who gives a fuck what you think, the report will be posted on every Intel thread, if any of you fanbois mod it down, it'll be posted on dozens of other threads.

    Understand? Now shut the fuck up.

  27. This is what we call a 'workaround'. by xxxLCxxx · · Score: 1

    This is what we call a 'workaround'.
    If somebody beats you up every time you go to the supermarket, the fix would be to get this slugger arrested. Now you can go to the supermarket without a hassle.
    The alternative would be to walk around the block and avoid that battler. This is what Intel has chosen as their 'solution'.
    I'm not judging, I'm merely pointing out the difference.

  28. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    Content doesn't trump method. Your method deserves a -1 and if you think that you're getting a -1 because of your content, you're clinging to a delusion of persecution to make yourself feel special. Grow the fuck up.

    And first post is now (Score:2, Informative) so fuck you and your worthless fanboi opinion.

  29. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    God, this site is crap now.