intel / intel/confidential-computing.sgx.sdk

Core dump caused by calling ecall multiple times

Open
#144 2 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
C++
Stars
2
Forks
3
PR merge metrics
No merged PRs in 30d

Description

Hi,
I am using Intel sgx SDK 2.22 to build an application.
My application triggers by design an ecall multiple times since it is located in a while loop.

After some iterations, the enclave crashes. I used sgx-gdb that gave me this result:

```
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140701950515456) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: No such file or directory.
[Current thread is 1 (Thread 0x7ff7b9c79900 (LWP 204777))]
(gdb) bt
#0 __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140701950515456) at ./nptl/pthread_kill.c:44
intel/confidential-computing.sgx#1 __pthread_kill_internal (signo=6,
threadid=140701950515456) at ./nptl/pthread_kill.c:78
intel/confidential-computing.sgx#2 __GI___pthread_kill (threadid=140701950515456,
signo=signo@entry=6) at ./nptl/pthread_kill.c:89
intel/confidential-computing.sgx#3 0x00007ff7b9642476 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
intel/confidential-computing.sgx#4 0x00007ff7b96287f3 in __GI_abort ()
at ./stdlib/abort.c:79
intel/confidential-computing.sgx#5 0x0000561457587796 in add_lost_keys_in_enclave (
local_lost_keys_set=std::set with 1 element = {...})
at App/TrustedLibrary/Types.cpp:139
```

This is the code of the add_lost_keys_in_enclave() function (which is called inside a while loop) where it systematically abort after some normal executions :

```
void add_lost_keys_in_enclave(const set& local_lost_keys_set){

string lost_keys_string="";
for (const auto& key_with_last_share_owner : local_lost_keys_set) {
lost_keys_string += key_with_last_share_owner+"\n";
}
sgx_status_t ret = SGX_ERROR_UNEXPECTED;
ret = ecall_add_lost_keys(global_eid, convertCString(lost_keys_string));
if (ret != SGX_SUCCESS)
abort();

}
```

What can I do to circumvent this issue ?

Contributor guide

Open the contributing guide

Research direction

Start with App/TrustedLibrary/Types.cpp:139 and the add_lost_keys_in_enclave() call path. Reproduce the failure across repeated loop iterations, inspect the return value from ecall_add_lost_keys and the surrounding SGX status handling, then determine what condition causes the non-success result. Done means identifying and documenting a reproducible cause and a validated way to prevent the abort.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.