[lowrisc-dev] New security concept: Seperated Stack
aurelien.francillon at eurecom.fr
Fri Feb 20 22:52:37 GMT 2015
Hi Philipp, Hi list,
this is an interesting idea, but not very novel :)
I actually wrote a paper about an implementation of a return stack on
the AVR . I was not the first to think about it and there have been
other similar proposals since then.
This said, this seems redundant with the tagged memory. A tag can
have the same effect as a separate return stack to protect return
addresses (or other code pointers for that matter).
Le Fri, Feb 20, 2015 at 11:26:11PM +0100, Philipp Gühring a écrit :
> I have an idea that I would like to contribute to LowRISC:
> Seperated Stacks.
> The problem I see with most current CPU´s and software stacks running on
> them is that they have merged the program stack and the data stack into a
> single stack. This results in various problems like stack overflows, stack
> underflows, return-oriented programming and various other exploits.
> My idea is to seperate the program stack (which would just contain the
> fixed size return addresses) from the data stack (which would contain the
> data), and put them into different segments.
> >From my experience, most exploits are overflowing/underflowing the data
> stack, not the code stack. So by simply seperating both stacks, you can
> protect the code stack from any exploits on the data stack.
> I tried to implement a proof-of-concept with Linux and Windows on X86 some
> time ago, but it was very hard to find free and reuseable registers for
> the seperated stacks on X86.
> What I think is necessary is:
> * A CodeStack-Segment register
> * A CodeStack-StackPointer register
> * A DataStack-Segment register
> * A DataStack-StackPointer register
> * The necessary opcodes to cope with them
> If you were able to add those to your LowRISC architecture, and the
> compilers would be adapted to make use of the added registers, to generate
> code that utilizes seperated stack code, I think that would be a huge step
> to protect the whole platform against most of the buffer overflows and
> While you are at it, I would also suggest to implement something like
> Google Native´s client NACL instruction in hardware.
> Best regards,
> Philipp Gühring
More information about the lowrisc-dev