volcano

I plan to support `Intel SGX SDK 2.17` on both `v1` and `v2`. The upgrade will be done soon.

@cschramm Thank you very much for your detailed problem analysis and test report. I plan to support three build strategies in the next release: 1. `no_std` 2. build-std in `xargo`...

@cschramm @PiDelport `teaclave-sgx-sdk v2.0.0`([https://github.com/apache/incubator-teaclave-sgx-sdk/tree/v2.0.0-preview](url)) already supports compiling enclave with `cargo-std-aware`.

There is a levelDB in teaclave that can be implemented in SGX that you can use as a reference. [https://github.com/apache/incubator-teaclave/tree/master/common/rusty_leveldb_sgx](url)

I think the first approach is better.

You can try two methods: 1.sgx_std::alloc::set_alloc_error_hook. Custom memory allocation error handling function. 2.sgx_signal::exception::register_exception Register exception handling function to capture SIGILL signal. example: https://github.com/apache/incubator-teaclave-sgx-sdk/blob/master/samplecode/unit-test/enclave/src/test_exception.rs Although you can capture the event of...

The registered signal handler can return two states: 1.ContinueType:Search Continue searching for the next registered signal handler. 2.ContinueType::Execution Continue to execute the instruction that caused the exception. If the exception...

@assafmo Before registering the exception handler, has the alloc::set_alloc_error_hook function been called to set the allocation failure handler? ``` alloc::set_alloc_error_hook(|layout| { println!("memory allocation of {} bytes failed", layout.size()); unsafe {...

@assafmo If the enclave passes the stack size limit, EALL will return SGX_ERROR_STACK_OVERRUN. Enclave thread context memory layout: guard page | stack | guard page | TCS | SSA |...

I haven’t found a simple way to recover from this, because the stack has been overused, and exceptions may occur when running any code. One possible way is to use...