Dmitrii Kuvaiskii comments

Results 681 comments of


                                            Dmitrii Kuvaiskii

[LibOS] tmpfs: no limit on file size

What @boryspoplawski said is correct. There are no issues (to the best of my knowledge) with running Gramine with `sgx.enclave_size = "512G"`. On the other hand, I've only seen people...

[LibOS] tmpfs: no limit on file size

> My guess is that paging to non EPC memory should still be faster or comparable to disk io? Yes, paging EPC -> RAM is typically faster than swapping RAM...

pytorch example failing for CentOS/RHEL machine

Here is the snippet from the error log: ``` [P1:T115:platform-python3.6] trace: ---- shim_mmap(0, 0x8002000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0x0) ... [P1:T115:platform-python3.6] trace: ---- return from shim_mmap(...) = -12 [P1:T115:platform-python3.6] debug: memory...

pytorch example failing for CentOS/RHEL machine

@aniket-intelx Interesting. What about setting `loader.env.OMP_NUM_THREADS = "8"`, for example? This is supposed to force PyTorch to use only 8 threads (instead of 115 or more). For this experiment, `sgx.enclave_size`...

pytorch example failing for CentOS/RHEL machine

Nice! @aniket-intelx Are you planning to submit a PR to fix PyTorch example with this setting (`OMP_NUM_THREADS`) + a comment explaining this?

[LibOS] `execve` syscall must treat `argv == NULL` as `argv = {NULL}`

Unfortunately, the current quirk in Gramine with respect to `envp` prevents us from performing `envp = {NULL}` conversion. See this code: https://github.com/gramineproject/gramine/blob/546c598b694d091121babc215bf6b9f9f52bbb4d/libos/src/sys/libos_exec.c#L150-L152 Also see a previous attempt at fixing a...

Efficiently Supporting Cloud Frameworks by reusing enclaves and specializing manifests

> @mkow > ...resetting the whole internal Gramine state correctly is quite challenging. Actually, isn't it what our `execve()` emulation supposed to do? See https://github.com/gramineproject/gramine/blob/9774ce1ca8551b868c1ca6c423dfcf1b010115d4/LibOS/shim/src/sys/shim_exec.c#L32?plain. > @mkow > I'm afraid...

[LibOS] time zone is incorrect in syscall `gettimeofday()` or glibc `localtime()` or bash command `date`

@lejunzhu @llly Looks like we have two separate issues here: 1. Time syscalls ignore the `struct timezone` argument completely, e.g. https://github.com/gramineproject/gramine/blob/9eafa5f7731650dc54043e4aa4804b6a2e34e292/LibOS/shim/src/sys/shim_time.c#L14 2. Gramine's patched Glibc needs special enablement in the...

[LibOS] time zone is incorrect in syscall `gettimeofday()` or glibc `localtime()` or bash command `date`

From what I read, `prefix=/usr` is the correct way to build Glibc that will use system-wide configuration files: https://sourceware.org/glibc/wiki/Testing/Builds#:~:text=Building%20glibc%20without%20installing,-To%20build%20glibc&text=By%20building%20with%20the%20prefix,prefix%20for%20a%20system%20glibc. @woju @pwmarcz @mkow Summoning you.

[LibOS] time zone is incorrect in syscall `gettimeofday()` or glibc `localtime()` or bash command `date`

> `configure --sysconfdir=/etc` should work Then I vote for this! Nice and contained. > But I don't understand why we need to mimic system's glibc 1:1, because we're really an...