7 ms·

If CPU brach predictor had bits of information readily available to check buffer boundaries and privilege level of the code, all this would be much easier to pr

by rini17 1y ago

If CPU brach predictor had bits of information readily available to check buffer boundaries and privilege level of the code, all this would be much easier to prevent. But apparently that will only happen when we pry out the void* from the cold C programmers' hands and start enriching our pointers with vital information.

ajross 1y ago
I don't see how you think that will help? It's not about software abstraction, it's about hardware. Changing the "pointer" does nothing to the transistors. Doing what you want would essentially require a hardware architecture where every load/store has to go through some kind of "augmented address" that stores boundary information. Which is to say, you're asking for 80286 segmentation. We had that, it didn't do what you wanted. And the reason is that those segment descriptors need to be loaded by software that doesn't mess things up. And it doesn't, it's "just a pointer" to software and amenable to the same mistakes.
- nottorp 1y ago
  I suppose a CPU that only runs Rust p-code is what the OP is dreaming about...
  - ajross 1y ago
    Generated rust "p-code" would presumably be isomorphic to LLVM IR, which doesn't have this behavior either and would be subject to the same exploits. Again, it's just not a software problem. In the real world we have hardware that exposes "memory" to running instructions as a linear array of numbers with sequential addresses. As long as that's how it works, you can demand an out of bounds address (because the "bounds" are a semantic thing and not a hardware thing). It is possible to change that basic design principle (again, x86 segmentation being a good example), but it's a whole lot more involved than just "Rust Will Fix All The Things".
    - nottorp 1y ago
      Holy... I need to stop making fun of Rust (*). I keep getting misinterpreted. (*) ... although I don't think I can abstain ...
- nine_k 1y ago
  Why stop at 80286, consider going back to the ideas of iAPX432, but with modern silicon tech and the ability to spend a few million transistors here and there. (CHERI already exists on ARM and RISC-V though.)
  - ajross 1y ago
    FWIW, the 286 launched like four months after the 432.
- rini17 1y ago
  286 far pointers were used sparingly, to save precious memory. Now we don't have any such problem and there are still unused bits in pointers even on largest 64 bit systems that might be repurposed perhaps. With virtual memory, there are all kinds of hardware supported address mappings and translations and IOMMU already so adding more transistors isn't an issue. The issue is purely cultural as you have just shown, people can't imagine it.
  - ajross 1y ago
    That's misunderstanding the hardware. All memory access on a 286 was through a segment descriptor, every access done in protected mode was checked against the segment limit. Every single one. A "far pointer" was, again, a *software* concept where you could tell the compiler that this particular pointer needed to use a different descriptor than the one the toolchain assumed (by convention!) was loaded in DS or SS.
quotemstr 1y ago
You want CHERI.
ActorNightly 1y ago
Or people could just understand the scope of the issue better, and realize that just because something has a vulnerability doesn't mean there is a direct line to an attack. In the case of speculative execution, you need an insane amount of prep to use that exploit to actually do something. The only real way this could ever be used is if you have direct access to the computer where you can run low level code. Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets. And in the case of systems that are valuable enough to exploit with a risk of a dedicated private or state funded group doing the necessary research and targeting, there should be a system that doesn't allow unauthorized arbitrary code to run in the first place. I personally disable all the mitigations because performance boost is actually noticeable.
- vlovich123 1y ago
  > Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack. > I personally disable all the mitigations because performance boost is actually noticeable. Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.
  - nine_k 1y ago
    Disabling some mitigations makes sense for an internal box that does not run arbitrary code from the internet, like a build server, or a load balancer, or maybe even a stateless API-serving box, as long as it's not a VM on a physical machine shared with other tenants.
    - anyfoo 1y ago
      You run "arbitrary code from the internet" as soon as you use a web browser with JS enabled.

by rini17 1y ago

ajross 1y ago

I don't see how you think that will help? It's not about software abstraction, it's about hardware. Changing the "pointer" does nothing to the transistors. Doing what you want would essentially require a hardware architecture where every load/store has to go through some kind of "augmented address" that stores boundary information. Which is to say, you're asking for 80286 segmentation. We had that, it didn't do what you wanted. And the reason is that those segment descriptors need to be loaded by software that doesn't mess things up. And it doesn't, it's "just a pointer" to software and amenable to the same mistakes.

nottorp 1y ago
I suppose a CPU that only runs Rust p-code is what the OP is dreaming about...
- ajross 1y ago
  Generated rust "p-code" would presumably be isomorphic to LLVM IR, which doesn't have this behavior either and would be subject to the same exploits. Again, it's just not a software problem. In the real world we have hardware that exposes "memory" to running instructions as a linear array of numbers with sequential addresses. As long as that's how it works, you can demand an out of bounds address (because the "bounds" are a semantic thing and not a hardware thing). It is possible to change that basic design principle (again, x86 segmentation being a good example), but it's a whole lot more involved than just "Rust Will Fix All The Things".
  - nottorp 1y ago
    Holy... I need to stop making fun of Rust (*). I keep getting misinterpreted. (*) ... although I don't think I can abstain ...
nine_k 1y ago
Why stop at 80286, consider going back to the ideas of iAPX432, but with modern silicon tech and the ability to spend a few million transistors here and there. (CHERI already exists on ARM and RISC-V though.)
- ajross 1y ago
  FWIW, the 286 launched like four months after the 432.
rini17 1y ago
286 far pointers were used sparingly, to save precious memory. Now we don't have any such problem and there are still unused bits in pointers even on largest 64 bit systems that might be repurposed perhaps. With virtual memory, there are all kinds of hardware supported address mappings and translations and IOMMU already so adding more transistors isn't an issue. The issue is purely cultural as you have just shown, people can't imagine it.
- ajross 1y ago
  That's misunderstanding the hardware. All memory access on a 286 was through a segment descriptor, every access done in protected mode was checked against the segment limit. Every single one. A "far pointer" was, again, a *software* concept where you could tell the compiler that this particular pointer needed to use a different descriptor than the one the toolchain assumed (by convention!) was loaded in DS or SS.

quotemstr 1y ago

You want CHERI.

ActorNightly 1y ago

Or people could just understand the scope of the issue better, and realize that just because something has a vulnerability doesn't mean there is a direct line to an attack. In the case of speculative execution, you need an insane amount of prep to use that exploit to actually do something. The only real way this could ever be used is if you have direct access to the computer where you can run low level code. Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets. And in the case of systems that are valuable enough to exploit with a risk of a dedicated private or state funded group doing the necessary research and targeting, there should be a system that doesn't allow unauthorized arbitrary code to run in the first place. I personally disable all the mitigations because performance boost is actually noticeable.

vlovich123 1y ago
> Its not like you can write JS code with this that runs on browsers that lets you leak arbitrary secrets That's precisely what Spectre and Meltdown were though. It's unclear whether this attack would work in modern browsers but they did reenable SharedArrayBuffer & it's unclear if the existing mitigations for Spectre/Meltdown stimy this attack. > I personally disable all the mitigations because performance boost is actually noticeable. Congratulations, you are probably susceptible to JS code reading crypto keys on your machine.
- nine_k 1y ago
  Disabling some mitigations makes sense for an internal box that does not run arbitrary code from the internet, like a build server, or a load balancer, or maybe even a stateless API-serving box, as long as it's not a VM on a physical machine shared with other tenants.
  - anyfoo 1y ago
    You run "arbitrary code from the internet" as soon as you use a web browser with JS enabled.