I was reading the most recent issue of ";login" which talked about security features and stack issues, and I got thinking about how the stack behaves and came back to some loose ideas:

Have any CPUs implemented some kind of restricted stack access, if not multiple stacks?
I was thinking something along the lines that you have a stack where you can only store call return addresses (or like only store the contents of the RISC link register). This would need MMU support.
Then you have a second stack register for all kinds of temporary storage. These two would be in different parts of memory.

I don't know if that would be workable, but isn't the problem that mixing data and code pointers lead to exploitable options?
(Bonus Q: What is the Right Way(TM) to grow the stack - up or down in memory?)

I'm not sure what kind of answer you're looking for; but Forth always has at least two stacks, the data stack and the return stack. The return stack can hold temporary data too, but not operate on it there; and the data stack can hold basically anything that fits in its cells, whether integer data, signed or unsigned, addresses, indexes, sometimes floating-point numbers, use two or more cells for multiple-precision numbers, etc.. Sometimes floating-point, if implemented, is given its own stack. You could easily implement other stacks, like for complex numbers, strings, etc.. I find the absence of typing to be a great benefit. Like Chuck Moore (the inventor of Forth) said, "If I want to take "a" and add 1 to it to get "b", it's none of the compiler's business to tell me I can't!" And I don't get errors from the fact that it does not have and enforcing typing.

I've never worked with an MMU; but if the application thinks that everything in it starts at a given address every time, even though the MMU puts it at another address, I don't expect any problems.

I have a 6502 treatise on stacks (plural, not just the page-1 hardware stack), with 19 chapters plus appendices, at http://wilsonminesco.com/stacks/ . The programming is mainly assembly language, but some of it is to do it in a way similar to how it's done in Forth, using a zero-page data stack. There are also chapters on using the page-1 hardware stack for temporary variables and for passing parameters, and for recursion, like some other languages use internally.

Growing the stack down has an advantage is that if the top of the stack is the lowest address, then indexing with 101,X gives the top stack byte, 102,X gives the second, 103,X gives the third, etc..

The most recent cores I’ve worked on support stack bound registers to allow exceptions if a stack reference is outside of range. They also support multiple stack register for different operating levels.

I’m not sure about this, but using handles rather than pointers may help here.

According to me: down. But it may depend what the hardware supports.

I used to think that an upward-growing stack would be a simple tactic to avoid many of the overflow problems we get: instead of overwriting stack contents, an overrunning index would just access elements beyond the stack. But, I think this is not so easy: it's normal to put an upward-growing heap at the bottom of memory and a downward-growing stack at the top, maximising the available space. If the stack is flipped then you'd probably want to flip the heap too, which means revisiting some stable code and rewriting some low-level libraries.

A non-executable stack is helpful for safety, but not a panacea for security - return-oriented-programming defeats it. Canaries on the stack also help, but that's a software fix.

A strict separation of code and data, either by address or by protection, seems like a win. But you need to be able to set it up and adjust it, and you need to be able to load programs which means promoting data to code, and to do all that safely, you need to add privilege levels to your architecture, and you need to get all the details right.

I recall some really early machine - a drum-based machine - had some strong distinction between code and data. The problem, and various solutions, have been around for a long time.

By coincidence, just found an early machine with tagged memory:

- from http://www.cpushack.com/2015/04/18/the- ... mainframe/

Edit: I think this isn't the "early machine" I was thinking of. That just had some even/odd distinction.

It seems Mill is guarding its stack content by having a separate instruction address stack if I understood this talk right: https://www.youtube.com/watch?v=XJasE5aOHSw