Last visit was: Sun Aug 09, 2020 1:44 am
It is currently Sun Aug 09, 2020 1:44 am



 [ 6 posts ] 
 Models for stack operation? 
Author Message

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 44
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?)


Wed Apr 12, 2017 11:17 pm

Joined: Tue Dec 11, 2012 8:03 am
Posts: 280
Location: California
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..

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Thu Apr 13, 2017 3:02 am WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 1137
Location: Canada
Quote:
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.

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.
Quote:
I don't know if that would be workable, but isn't the problem that mixing data and code pointers lead to exploitable options?

I’m not sure about this, but using handles rather than pointers may help here.
Quote:
(Bonus Q: What is the Right Way(TM) to grow the stack - up or down in memory?)

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

_________________
Robert Finch http://www.finitron.ca


Thu Apr 13, 2017 8:26 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1430
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.


Fri Apr 14, 2017 8:32 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1430
By coincidence, just found an early machine with tagged memory:
Quote:
In 1969 the B6500 was released, improving on the design and with it the MCP (Master Control Program). MCP was Burroughs operating system, and what came to define their machines for the decades to come. The B6000 line (like the B5000) was a 48-bit architecture. In addition to the 48-bit data size was a 3-bit tag that told the system what that data was, code, data, type, etc. This simplified the instruction set greatly as instruction need not be specific to each data type, they could check the tag and know what type of data. Coincidentally this also allowed for greater security as well, many of the buffer overflow exploits we have seen in the modern day were not possible on a Burroughs, the tag did not allow data to be executed as code, essentially it could perform as a NX flag (No Execute) such as is on modern x86 processors.

- 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.


Thu Apr 20, 2017 9:32 am

Joined: Thu Jan 17, 2013 4:38 pm
Posts: 44
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


Sat Oct 07, 2017 6:39 am
 [ 6 posts ] 

Who is online

Users browsing this forum: CCBot, PetalBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software