corner case delay_instruction() during asm_thread_fork wrappers can clobber other thread's stack

[bblum]

For example, a particular P2 which will go unnamed had the following (ALSO buggy) thread fork implementation.

If you put a DR PP on either line marked XXX,

when we go to delay the instruction, delay_instruction will choose %esp-8 for its instruction buffer, BUT THAT ESP IS SHARED WITH THE PARENT THREAD, and the other thread's stack will get clobbered.

010009e1 <thread_fork>:
 10009e1:       cd 52                   int    $0x52
 10009e3:       85 c0                   test   %eax,%eax
 10009e5:       75 0a                   jne    10009f1 <thread_fork_end>
 10009e7:       8b 4c 24 04             mov    0x4(%esp),%ecx // XXX
 10009eb:       8b 14 24                mov    (%esp),%edx    // XXX
 10009ee:       89 cc                   mov    %ecx,%esp
 10009f0:       52                      push   %edx

[bblum]

A bug in the student thread fork implementation is not mandatory to expose the landslide bug.

If instead of reading from 0x4(%esp), we loaded from esp into ebp or whatever before the int instruction, and from there loaded from some shared address (that was otherwise synchronized to be safe), a DR PP could be placed and esp would still mirror the parent thread's esp.

[bblum]

Right now I'm going to switch the attempt order of _end vs esp-8. But a real solution should never use esp-8, at least not when testing userspace. There should be a config.landslide option to specify the name of a designated safe global buffer that you can annotate (in my case, by hacking the p2 basecode). And _end would be used if that annotation is missing, and if _end is page aligned, it simply asserts instead of trying esp.

[bblum]

(couldn't get GUEST_IMG_END for kernel space delay instruction to work in pathos, don't know why)