DONTMERGE Rework of PR 1857

[dimakuv]

Description of the changes

It turned out to be easier to try to implement this myself.

How to test this PR?

I was trying Redis in Debug mode (works) and in Release mode (works).

---

This change is 

[dimakuv]

Reviewable status: 0 of 5 files reviewed, 1 unresolved discussion, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "DONTMERGE" and "fixup! " found in commit messages' one-liners

---

pal/src/host/linux-sgx/host_entry.S line 82 at r1 (raw file):

    #        RPC request objects, as the AEX flow here. It just so happens that the total size of
    #        allocated RPC request objects is less than 128B (red zone size), so I reuse this const.
    #        This double-stack-usage needs a proper fix.

These are the references:

• gramine/pal/src/host/linux-sgx/enclave_framework.c

  Lines 95 to 96 in 951795e

  	if (ustack != GET_ENCLAVE_TCB(ustack_top))
  	ustack -= RED_ZONE_SIZE;

• gramine/pal/src/host/linux-sgx/enclave_ocalls.c

  Lines 54 to 55 in 951795e

  	/* allocate request in a new stack frame on OCALL stack; note that request's lock is used in
  	* futex() and must be aligned to at least 4B */

Note how the red zone is accounted for in the preparation of the untrusted stack, and then the RPC request object is allocated from below that red zone. That's why we need two red zones in this workaround here.

This problem is unrelated to this PR really. Fundamentally this AEX handler and the OCALL logic re-use the same stack, and can do it at the same time. We were just lucky that the AEX handler didn't use the stack, or used the stack but only in DEBUG mode.

I feel like the OCALL stack should be a different memory region than the stack. Guess that's the correct solution.

[dimakuv]

Reviewable status: 0 of 7 files reviewed, 2 unresolved discussions, not enough approvals from maintainers (2 more required), not enough approvals from different teams (1 more required, approved so far: Intel), "fixup! " and "DONTMERGE" found in commit messages' one-liners

---

pal/src/host/linux-sgx/host_entry.S line 75 at r2 (raw file):

    # Inform that we are in AEX profiling code
    movb $1, %gs:PAL_HOST_TCB_IN_AEX_PROF

I think the name of this variable/macro should be changed, dropping _PROF. Now AEX doesn't do only profiling but more.

Also, this asm line should be moved before the previous (lock inc) line.

[dimakuv]

Jenkins, test this please

[dimakuv]

All code was moved into the main PR #1857, so I'm closing this "proof of concept" PR

[dimakuv]

pal/src/host/linux-sgx/host_entry.S line 82 at r1 (raw file):

Previously, dimakuv (Dmitrii Kuvaiskii) wrote…

These are the references:

• gramine/pal/src/host/linux-sgx/enclave_framework.c

  Lines 95 to 96 in 951795e

  	if (ustack != GET_ENCLAVE_TCB(ustack_top))
  	ustack -= RED_ZONE_SIZE;

• gramine/pal/src/host/linux-sgx/enclave_ocalls.c

  Lines 54 to 55 in 951795e

  	/* allocate request in a new stack frame on OCALL stack; note that request's lock is used in
  	* futex() and must be aligned to at least 4B */

Note how the red zone is accounted for in the preparation of the untrusted stack, and then the RPC request object is allocated from below that red zone. That's why we need two red zones in this workaround here.

This problem is unrelated to this PR really. Fundamentally this AEX handler and the OCALL logic re-use the same stack, and can do it at the same time. We were just lucky that the AEX handler didn't use the stack, or used the stack but only in DEBUG mode.

I feel like the OCALL stack should be a different memory region than the stack. Guess that's the correct solution.

This comment is wrong and stale. The problem was in other two places, see the changes in this PR in files enclave_framework.c and enclave_ocalls.c.

Note that the latter place (actual bug) was fixed in a separate PR: #1955