4 ms·

Wait, it's not about addressability, but essentially about type confusion - typically data that is not actually a code pointer suddenly gets used as such by `re

Wait, it's not about addressability, but essentially about type confusion - typically data that is not actually a code pointer suddenly gets used as such by `ret`. If you are running on a machine that can push an integer but pop it as something else you're still in trouble. BTW, signed pointers are essentially a type check mechanism, where forging types is hard.

Joker_vD 3y ago
The activation records don't have to be stored in one piece: it's entirely possible to have a call stack that stores only return addresses and a data stack that stores frames of local variables (that's how you'd normally program e.g. on 6502). Which is a scenario that x64 arguably supports too, having separate RSP and RBP registers, with RBP-addressing being nice and easy and RSP-relative addressing encoded very cumbersomely.
- Vogtinator 3y ago
  There's AMD shadow stack and Intel CET which do that as well. For compatibility, the return address is also on the data stack, but verified with the address stack.
  - titzer 3y ago
    CET complicates software virtual machines in several ways, e.g. deoptimization and exception handling. It's the wrong solution to a software problem that should never have arisen and just makes software even more complicated. An unfortunate metastasis of running unsafe code without checks for too long.
- Findecanor 3y ago
  Clang/LLVM supports such a scheme. It saves other variables that don't need to be dereferenced there too. Many utilities on several BSDs are compiled with it, but are necessarily statically linked. <https://clang.llvm.org/docs/SafeStack.html https://clang.llvm.org/docs/SafeStack.html> It is also the default on Fuchsia, which therefore supports shared libraries. <https://fuchsia.dev/fuchsia-src/concepts/kernel/safestack https://fuchsia.dev/fuchsia-src/concepts/kernel/safestack> The problem with these software-based approaches is that it is security-by-obscurity, which breaks if the address to the safe stack would leak. Like ASLR, it is considered more or less broken on 32-bit systems where it is easier to allocate significant portions of the address space to find where it is not and then do educated guesses. However, there have been a few papers using Intel's MPK or even CET to protect it properly, at some performance cost of course. It was also the model that Itanium used. You got the return address in a register and because register windows were saved to a separate stack, it thus saved the return address there too.
- johnklos 3y ago
  Funny that you use the term "x64", which is a technically incorrect way to refer to 64 bit x86 / amd64. If anything, "x64" refers to Alpha: 21064, 21164, 21264, 21364.
  - Joker_vD 3y ago
    If the thing is widely being known as "x64", then "x64" is that thing's name. That's what the word "name" means. And if you want to be picking nits, it's actually EM64T or at the very worst, IA-32e. Then again, there are actually two versions of this ISA and Intel is currently calling its version "Intel 64" (and AMD used to call their pre-release version "x86-64", by the way), but definitely not "64-bit x86". Edit: Oh hey, you're the same guy who made that silly argument 11 months ago [0]. Never mind me then. [0] https://news.ycombinator.com/item?id=33097250 https://news.ycombinator.com/item?id=33097250
    - johnklos 3y ago
      This is in a thread that's about various CPUs INCLUDING Alpha. Good job ;)
      - kjs3 3y ago
        I sure hope you don't call those boxes full of electronics being discussed 'computers' since that's obviously a technically incorrect way to refer to them[1]. [1] https://en.wikipedia.org/wiki/Computer_(occupation) https://en.wikipedia.org/wiki/Computer_(occupation)
        johnklos 3y ago
        Your pedantry is incorrect. Computers are people who compute and machines that compute. The point is that in a discussion that includes Alpha, "x64" obviously isn't clear. Doubling down with "but everyone does it" isn't a good look.
        Moomoomoo309 3y ago

Joker_vD 3y ago

The activation records don't have to be stored in one piece: it's entirely possible to have a call stack that stores only return addresses and a data stack that stores frames of local variables (that's how you'd normally program e.g. on 6502). Which is a scenario that x64 arguably supports too, having separate RSP and RBP registers, with RBP-addressing being nice and easy and RSP-relative addressing encoded very cumbersomely.

Vogtinator 3y ago
There's AMD shadow stack and Intel CET which do that as well. For compatibility, the return address is also on the data stack, but verified with the address stack.
- titzer 3y ago
  CET complicates software virtual machines in several ways, e.g. deoptimization and exception handling. It's the wrong solution to a software problem that should never have arisen and just makes software even more complicated. An unfortunate metastasis of running unsafe code without checks for too long.
Findecanor 3y ago
Clang/LLVM supports such a scheme. It saves other variables that don't need to be dereferenced there too. Many utilities on several BSDs are compiled with it, but are necessarily statically linked. <https://clang.llvm.org/docs/SafeStack.html https://clang.llvm.org/docs/SafeStack.html> It is also the default on Fuchsia, which therefore supports shared libraries. <https://fuchsia.dev/fuchsia-src/concepts/kernel/safestack https://fuchsia.dev/fuchsia-src/concepts/kernel/safestack> The problem with these software-based approaches is that it is security-by-obscurity, which breaks if the address to the safe stack would leak. Like ASLR, it is considered more or less broken on 32-bit systems where it is easier to allocate significant portions of the address space to find where it is not and then do educated guesses. However, there have been a few papers using Intel's MPK or even CET to protect it properly, at some performance cost of course. It was also the model that Itanium used. You got the return address in a register and because register windows were saved to a separate stack, it thus saved the return address there too.
johnklos 3y ago
Funny that you use the term "x64", which is a technically incorrect way to refer to 64 bit x86 / amd64. If anything, "x64" refers to Alpha: 21064, 21164, 21264, 21364.
- Joker_vD 3y ago
  If the thing is widely being known as "x64", then "x64" is that thing's name. That's what the word "name" means. And if you want to be picking nits, it's actually EM64T or at the very worst, IA-32e. Then again, there are actually two versions of this ISA and Intel is currently calling its version "Intel 64" (and AMD used to call their pre-release version "x86-64", by the way), but definitely not "64-bit x86". Edit: Oh hey, you're the same guy who made that silly argument 11 months ago [0]. Never mind me then. [0] https://news.ycombinator.com/item?id=33097250 https://news.ycombinator.com/item?id=33097250
  - johnklos 3y ago
    This is in a thread that's about various CPUs INCLUDING Alpha. Good job ;)
    - kjs3 3y ago
      I sure hope you don't call those boxes full of electronics being discussed 'computers' since that's obviously a technically incorrect way to refer to them[1]. [1] https://en.wikipedia.org/wiki/Computer_(occupation) https://en.wikipedia.org/wiki/Computer_(occupation)
      - johnklos 3y ago
        Your pedantry is incorrect. Computers are people who compute and machines that compute. The point is that in a discussion that includes Alpha, "x64" obviously isn't clear. Doubling down with "but everyone does it" isn't a good look.
        Moomoomoo309 3y ago