From:  "Nicolas B. Pierron" <>
Date:  22 Mar 2017 23:44:16 Hong Kong Time

Re: How to implement the security scheme that prevents the RET instructions from being misused


On 03/22/2017 04:07 AM, Yuan Pinghai wrote:
> In my current design, the cookie is stored in a new field (named
> retCookie_) of JitCode, and each JITCODE (representing an instance of
> JitCode) has its own cookie. In this way, when i need the original
> return-address, i can recover it by first getting the JITCODE and then
> fetching the cookie. Now, my problem is how can i get the correct JITCODE
> with an address (e.g. the interrupted address before bailing-out)?

The CalleeToken of JitFrameLayout frames holds either a JSFunction or a 
JSScript which contains a pointer to the Baseline and Ion structure 
containing references to the JitCode.

When a JitCode is invalidated (Ion), the JitCode pointer is written above 
the return address.  JitFrameIterator::ionScript() should do the proper work 
to get the information you are looking for.

Note that JitCode are used for all trampoline code which are created when 
the JitRuntime is created. (see Trampoline-*.cpp files) and these should be 
registered on the Runtime.

Our stack frames are making assumption about the alignment of the stack, 
thus if you add any fields in the CommonFrameLayout, or JitFrameLayout, 
these might cause issue in all code able to produce code, in which case you 
should look for MacroAssembler::call and MacroAssembler::callJit.

WebAssembly / Asm.js are not using any of the Jit frames.  Instead they are 
using the same frame layout as the ABI of the system, with some variations 
around the manipulation of SIMD registers.

> Could some body give me a tip? Any suggestions are welcome. I appreciate
> for the help!

To be honest, our stack frames are not the easiest thing to manipulate.

Maybe to prototype it, it would be easier to create some reserved memory 
which is used as a second stack space which only contains the cookies?

You could store them as part of the JSContext*, and fetch the one 
corresponding to the top of the stack.

> By the way, i am working on Spidermonkey 45. By honest, i don't think i
> have enough knowledge on fixing the bailing-out and exception handling
> mechanisms, i also need suggestions on them.

What are you issues with bailouts and exceptions?  They are basically 
reading a register dump from the stack to build a MachineState (structure of 
pointers to each register spilled location if any) and then unwind the frame 
and in case of a bailout replace it by the one created by Baseline.

What would matter would be to edit the return address, knowing the caller & 
callee, which you should have in both cases with the JitFrameIterator.

Nicolas B. Pierron