Dmitrii Kuvaiskii

The issue itself was resolved, closing.

This is still valid for the latest master: https://github.com/oscarlab/graphene/blob/af2f7809b36945382a535f95c2af7a2b32a2059a/LibOS/shim/src/sys/shim_alarm.c#L98 However, we haven't encountered any real-world applications that rely on this. So the priority is low.

+1 for re-using/freeing on the next-thread creation.

Just a note: `shim_thread` objects were leaked for "normal" threads. Even though these threads went through cleanup in LibOS's `thread_exit()` and their stacks were removed in PAL's `DkThreadExit()`, their `shim_thread`s...

It looks like the memory leak of PAL handle in `_DkThreadExit()` is still there. This is how it is created in both PALs: - https://github.com/oscarlab/graphene/blob/af2f7809b36945382a535f95c2af7a2b32a2059a/Pal/src/host/Linux-SGX/db_threading.c#L97 - https://github.com/oscarlab/graphene/blob/4f0927ff993c9e34aa20d6bad93fad47e2daa2ef/Pal/src/host/Linux/db_threading.c#L147 And there is...

This is a very small memory leak (hundred bytes for each thread?), so the priority is low.

Some additional info on a related issue in code. The termination of IPC Helper Thread checks for the state `HELPER_HANDEDOVER` (which would be better called `HELPER_PENDING_SHUTDOWN`). This state is set...

Maybe it's good time to implement emulation of a current user in Graphene? The current hard-coding of `0` (= root user) in Graphene is wrong, misleading and confuses everyone who...

> But there's no "current user", we're running a completely different OS instance than the host, so, passing host user id is conceptually wrong. What we can do is to...

> But there's no "current user", we're running a completely different OS instance than the host, so, passing host user id is conceptually wrong. Actually, why do you say that...