Announcement

Collapse
No announcement yet.

Retbleed Impact, Overall CPU Security Mitigation Cost For Intel Xeon E3 v5 Skylake

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • skeevy420
    replied
    Originally posted by Alexmitter View Post

    Inside the CPU, those modern ARM cores and modern x86 are not that different, they just have a different box before the actual CPU that translates whatever CISC instructions into what the actual RISC cores inside understand (intel calls those instructions uOps). x86 CPUs work like this since the days of the Pentium Pro.

    What you actually want are simple CPUs that can't do branch predict and do not use any of the other complex speed enhancing logic which you can find in any current x86 or ARM CPU and if you ask, you will find them too in most full featured RISCV cores.
    I meant to reply to birdie yesterday about that but had to leave before I could finish my post.

    Originally posted by birdie View Post

    x86 internally has long not been a classic x86 CISC architecture and all ARM CPUs affected by Spectre are also affected by Retbleed. Spectre-class vulnerabilities affect all existing uArchs featuring speculative execution.
    That's why I'm wondering if the path forward is some other architecture, we'll call it SimpleSecureArch, paired with insecure architectures that run in what would essentially be hardware VMs...like how the PS4 uses x86 for games and ARM for the OS. Based on the past it is only a matter of time before Zen 4 is compromised...and the next and the next... It just seems pointless to keep on down this path. If we know that they're fundamentally flawed then why not design a chip that has the flawed part isolated from the rest? Why design a chip with that flaw period?

    My thought process is that as we're getting to the shrinkage limits and maximum speeds possible, that speed enhancing logic is less and less necessary. Why not dumb down general purpose CPUs so the core of the system is inherently more secure.

    Why does x86 have to be the primary architecture?

    Why can't we plug in a branch prediction unit much like we plug in a graphics processing unit? A PCIe 16x 2 slot design with an 8c16t Ryzen and 4 slots of ram so your x86 BPU runs isolated from the rest of the OS/system so you don't have to run slow, mitigated code.

    Leave a comment:


  • rabcor
    replied
    Originally posted by bobbie424242 View Post
    mitigations=off
    Honestly i have mitigations=off too, with the exception of retbleed which is a new one, quite recently i dug into what exactly mitigations mitigates and as it turns out these are barely really threats for the average user. Critical i'm sure for enterprise servers and such, but honestly leaving mitigations off on linux is less worrying than just running windows, and about 90% of people run windows so...

    Leave a comment:


  • Anux
    replied
    Originally posted by mangeek View Post
    The enemy needs to be in the gates, so to speak (which is why I'd keep mitigating on systems that run browsers or have a lot of user interaction). The effort to exploit this is probably something that nation states would deploy against each other, not crimeware/ransomware groups... for now.
    Theoretically if only server/compute workloads are run you don't need the mitigation because there is never a situation that untrusted code gets executed. But this only holds true, if all your programms are bug free or there is no way to inject untrusted data.

    A simple bufferoverflow in a server that works with datasets from untrusted users is enough and someone else is admin or knows all you secret keys ...

    Leave a comment:


  • CochainComplex
    replied
    Originally posted by mangeek View Post

    The effort to exploit this is probably something that nation states would deploy against each other, not crimeware/ransomware groups... for now.
    Enough to leave it switched on for the majority of "classic" non-gov parts of the national infrastructure e.g. Energy, Banks, Big Corp, Healthcare, Telecom ...so basically everything but private computers (if not workplace related).
    Last edited by CochainComplex; 29 July 2022, 05:37 AM.

    Leave a comment:


  • CochainComplex
    replied
    now I know why the word "bleed" is used

    Leave a comment:


  • mangeek
    replied
    Originally posted by numacross View Post
    Has there been a reliable exploit for any of the speculative execution vulnerabilities yet? By "reliable" I mean usable on an actually working computer, and not in a strictly controlled laboratory setting.
    There has been PoC, but these things aren't traditional vulnerabilities... A lot of systems, even in the enterprise, could probably be safely run with mitigations=off. As an ITSec person, these present a lot of risk, but only in some specific scenarios (e.g., VDI where users can control what's happening, or on systems that are shared MSP hosts, or VM hosts with guests of vastly different security levels.)

    It's not a 'hackers will get you' thing, more like... if someone can set up camp with an APT and slowly trickle secrets away, this is a way to get that done. The enemy needs to be in the gates, so to speak (which is why I'd keep mitigating on systems that run browsers or have a lot of user interaction). The effort to exploit this is probably something that nation states would deploy against each other, not crimeware/ransomware groups... for now.
    Last edited by mangeek; 28 July 2022, 11:27 PM.

    Leave a comment:


  • rlkrlk
    replied
    Unfortunately, my Skylake laptop (Thinkpad P70) is going to be tricky to replace, because laptops with 2.5" bays (much less 2!) are hard to find, and I have big storage needs. External drives aren't the answer.

    Leave a comment:


  • numacross
    replied
    Great article with some ingenious workarounds to the mitigations. Modern browsers really are looking like operating systems.
    The DRAM attack made assumptions about THP usage, but still is a fun (and scary) idea.

    Leave a comment:


  • justinkb
    replied
    I was expecting worse tbh. Still... not great

    Leave a comment:


  • hotaru
    replied
    Originally posted by numacross View Post
    Thanks, I was aware of those and how they were mitigated by relaxing timer accuracy in JavaScript by browser vendors.

    Leave a comment:

Working...
X