211–220 of 349 posts
ISA complexity breeds microarchitecture bugs. In the internet era, x86 is an anachronism. RISC is the way forward. RISC-V is inevitable.
What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…
>In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal machine-readable specifications for the low-level operations of these chips. I hope you're not in charge of hiring QA. Bugs are often found by people who AREN'T thinking like th…
Earlier quoted context omitted.
The real problem here is the x86 architecture. We should stop using it. It's too complex, it's full of stuff made for backward compatibility purposes, it has too many instructions that may have unpredictable results, and for that exact reason it's extremely difficult to get things right. Somewhere in the thousands of instructions that it has you will surely find a bug. We should move forward. Apple did a great job wi…
Meltdown and Spectre affected ARM and POWER CPUs. Apple's included. PACMAN affected M1. The real problem is speculative execution seemingly.
This would also require changes at the OS-makers to tag thread forks for trusted and untrusted behavior.
Essentially: instead of shutting down SMT for the entire machine, make the customer "prove" the code is safe for elevation or else it gets scheduled as non-SMT.
What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…
Earlier quoted context omitted.
If so, all people relying on (often limited even with html that contains text) accessibility features will have to sit in a corner and cry.
I think that should be addressable.
What I find odd is that after the initial Spectre attacks, there have been a long string of these attacks discovered by outside researchers and then patched by the chipmakers. In principle it seems like the chipmakers should hold all the cards when it comes to discovery: they are experts in speculative execution, know exactly how their chips work and have massive existing validation suites, simulators and internal ma…
https://www.youtube.com/watch?v=WlcQrx7VK00 https://hardwear.io/usa-2023/presentation/the-microarchitect...
But it definitely seems to be a culture/disclosure problem.
(Also, hi - hope things are going well! We miss you on Mastodon)
Hear me out: Instead of making SMT an all-or-nothing pre oposition, we have "lousy cores" where untrusted code goes and make the customer "prove" it should get elevation to the cores with SMT?
I dont't want to clobber my chip that's running the mega-important payroll jobs where no one can load anything else on to the board under pain of death. However I would like to be forced into tagging what is safe to run SMT else I get stuck on the safer cores.
I might be an intern who has no idea what any of this stuff means and goes to Google it, then learn what this attack vector truly is. Then makes a plan on how to defend against it.
Am I crazy?
Earlier quoted context omitted.
Once you "dedicate cores to specific VMs" you will find that chip designers can also screw that up, just like they can screw up protection within a core. So you might as well proclaim that "impossible to get right" preemptively.
They said physical processor. I took this to mean chip. Of course you can't trust chips on the same mother board (there could be a bug where they can read the same memory), so you need a network boundary. So different rack on the server, for each [boundary, however you define that...]
Earlier quoted context omitted.
I think the comparison between CPU and software exploits holds at a very high level, but in the case of software the gap between internal and external researches seems lower. Much software is open-source, in which case the play field is almost level and even closed source software is available in assembly which exposes the entire attack surface in a reasonably consumable form. Software reverse-engineering is a hugely…
I'm not sure I agree significant gaps in the playing fields are really there. By significant I mean something that explains it should be e.g. 10x harder or something to the point it's supposed to be suspicious how the ratio is indicative of something off. Sure, you don't get to see how they laid out the transistors of the CPU but that's not how these attacks work it's by some oversight in memory handling not that dif…
Earlier quoted context omitted.
an easier explanation is that modern chipsets are incredibly complex, side channel attacks like these are hard to reason about and traditionally, processors themselves have not been the target of these kinds of attacks, so i don’t think the engineers working on them are accustomed to thinking about them as attack surfaces in this way.
You didn't have to think about this when you ran your code on your own chips; so it's your fault for backdooring the front end into the datacenter. But now we have the 21st-century mainframe we like to call the cloud, where everything is shared. So I upload a container image with the vampire vuln intending to read all the activity on the host. Other customers jobs, the OS itself, even steal internal keys used at Amaz…
There is the "just use OS/2" strategy of the 1990s (referring to the period from 1995-2002 where you could sit happy in your niche OS that researchers and BHs were not targeting): in this case s390x probably has the same problem but no one is paying attention to it (other than a 3 letter agency, of course), so the chances of a payload reaching that arch are very close to zero.