Peter Pietzuch

@vtikoo This may mean that the LKL termination sequence hasn't been triggered despite the fact that all application threads have exited.

Hmm, termination should be triggered by any application thread exiting: https://github.com/lsds/lkl/blob/e041aa71e03a142ecef542c005b07d13e2a3b722/arch/lkl/kernel/threads.c#L89

> There's one relevant getenv call in musl, see https://github.com/lsds/sgx-lkl-musl/blob/a6360f883fd906b18c1878254547ad72da28d7e6/ldso/dynlink.c#L822. This is now the only tracing/debug env var that gets passed through to the enclave as an env var: >...

Our code for injecting signals into LKL looks quite different from that of other Linux architectures: - We handle signals by directly invoking a handler here: https://github.com/lsds/lkl/blob/eecb2a320f3f2dd85942526df0a3d3abd402912c/arch/lkl/kernel/signal.c#L38 - In contrast,...

* `languages/nodejs` is currently broken because of https://github.com/lsds/sgx-lkl/issues/779. Hopefully this will be fixed soon. * `languages/openmp` is broken because of https://github.com/lsds/sgx-lkl/issues/535. This is due to a fundamental incompatibility, as documented...

@hukoyu when you look here (https://dev.azure.com/sgx-lkl/sgx-lkl/_build/results?buildId=921&view=logs&j=289c1492-6262-5ba1-59e0-a623a2e4156a&t=66dd73f4-5cb1-5a04-1123-cb2adebf7e9d), you will see several compilation failures, which is why LTP2 fails. This only happens sometimes, so I presume that the build environment is corrupted...

Thanks. Is the SIGPIPE received?

The samples almost completely overlap with the existing CI tests.

> This number is part of the attested config, i.e. it can't possibly depend on the host, because that would be unpredictable for anyone who wants to verify a quote...

> They may not know what type of VM their container is launched on, especially when their containers are launched as part of higher level workflows. I think it's best...