Code Data Isolation

[Simon Jackson]

https://kring.co.uk/2022/07/protected-modes/ is the rough outline for an ISA extension to mark code vs. data so as to split the source/target addresses based on typing or expected type.

PURPOSE

To prevent return oriented programming by altering the stack return pointer so preventing many cases of unexpected code reentry point programmatic malfunction for prevention of malware effectiveness.

It would be nice to get some open security analysis feedback.

Cheers

Simon

[MitchAlsup]

My 66000 architecture prevents Return Oriented Programming by placing the protected parts of

call-return interface on a stack where the code cannot access "wildly".

a) the Safe Stack pointer to this memory is not visible (unless one has GuestOS privilege)

....it sits over in a control register near where the IP is maintained.

b) the pages are translated with entries where RWE = 000 (no application access)

....the PTE's RWE is checked to be 000 by MMU.

c) only ENTER and EXIT and RET instructions can access this data.

d) preserved registers are marked to read as zero until written--so you don't know

....even what value was preserved on that other stack.

e) knowing that this memory area is really and only operated as an un-shared stack, new lines can 

....be allocated without coherence traffic, and discarded without writing back to memory. Improving

....memory efficiency.

The unprivileged attacker does not know where that stack is, and even if they did know, there have 

no memory reference access to it.

Subroutine Prologue and Epilogue sequences have free access to this stack, but not any

LDs or STs.

Thus attacker can overrun a buffer, and blow the data stack, but cause no harm to the preserved

state (return address is an important part of this state). Thus, an attacked subroutine will still

return to its caller and with all the preserved registers.

Also note: the programming model is identical with or without Safe Stack in use. The same

re-entrant shared binary can be called from un-safe-stack mode as well as Safe-Stack mode.

On Friday, July 8, 2022 at 5:18:25 AM UTC-5 jacko...@gmail.com wrote:

https://kring.co.uk/2022/07/protected-modes/ is the rough outline for an ISA extension to mark code vs. data so as to split the source/target addresses based on typing or expected type.

I looked at this briefly. You have a long way to go, but you understand many of the major point.

[Simon Jackson]

That's cool. The idea restrictions though are

1) must be ISA compatible.

2) must prevent code stack modification without kernel intervention

And possibly

3) must prevent call target execution being an illegal entry point (maybe an instruction NOP which indicates entry)

4) must prevent return target execution being an illegal return point (maybe checks if there is a call before)

Cheers

[MitchAlsup]

On Friday, August 5, 2022 at 3:51:55 AM UTC-5 jacko...@gmail.com wrote:

That's cool. The idea restrictions though are

1) must be ISA compatible.

The same code runs unmodified whether safe-stack is turned on or turned off.

Although in RISC-V's case, you would have to add instructions to access this stack. I will not coach you

on how to install appropriate instructions for this in RISC-V, as this is more CISCy than the underlying

philosophy of RISC-V.

 

2) must prevent code stack modification without kernel intervention

The Safe-stack is translated with page table entries having RWE = 000. Only the ENTER, EXIT, and RET instructions

(from My 66000) are allowed to access the safe-stack. Any LD or ST to the safe stack will raise a page-fault. 

PTE.RWE=000 is a no access page. When Safe-stack is turned on, ENTER checks that the PTEs translating

the Safe-stack address range have RWE=000--or the application will take a page fault. This is how I snuck

this functionality into My 66000 without blowing bits in the PTEs.

And possibly

3) must prevent call target execution being an illegal entry point (maybe an instruction NOP which indicates entry)

Call target must be a well formed FETCH address, translated with a RWE=001 PTE*.

 

4) must prevent return target execution being an illegal return point (maybe checks if there is a call before)

RET must fetch a well formed address from safe-stack, and the target of the return must be translated by a 

RWE = 001 PTE.

PTE.RWE=001 is a code only page.

A well formed address (in My 66000) has the 2 lower order bits = 00 (word), and is translated by a PTE with 

RWE = xx1 permissions. 

(*) code pages are not readable nor writeable in My 66000 (and checked by HW) there are different (and

efficient) mechanisms used by debuggers and JITs to "diddle" with code.

[Simon Jackson]

Yep, it still needs some work. Not needing a coach integration, more of coverage security open analysis.

The way call and return work on the RISC-V is not easily amenable to a security-first paradigm.