Christoph M. Wintersteiger
Christoph M. Wintersteiger
I'm aware of the request and I think we do definitely want to add that, but I'm too busy to implement it right now. I hope I'll find some time...
Yes, that's why we're doing this. It has to be absolutely clear what's attested and checked, and what's just copied over from/to the host.
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: https://github.com/lsds/sgx-lkl/blob/9979a88fa90cca275dcb0822deef5e0393cea88a/src/main-oe/sgxlkl_params.c#L3 I'm...
Great, thanks for the explanation, then it makes sense to keep it!
+1. I think this should be p0, it's the first thing prospective users will try!
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 later....
> then be surprised... If a user doesn't understand that their application is multi-threaded... :-) > As long as a user understands... They may not know what type of VM...
Yes, that's right, num_tcs would be an upper bound (currently num_tcs == num_ethreads). Actually, do we want the number of ethreads be an attested setting? This depends entirely on the...
That's a good idea, we could use that upper bound to enforce the maximum (num_tcs). What would happen if multiple malicious host-threads share one TCS so that the enclave can't...
Also fixes #732.