Dmitrii Kuvaiskii
Dmitrii Kuvaiskii
Looks like the issue is solved on the Gramine side (solution: do not use the latest QEMU v7.1). It would be interesting to debug why QEMU started failing, and how...
> On DCAP we just ignore these tokens? No. We *do* create a dummy token: https://github.com/gramineproject/gramine/blob/d5599d52d2076006d31493da00f096099298aaf0/python/graminelibos/sgx_get_token.py#L148-L149 But the attributes (SECS.ATTRIBUTES.XFRM) are unconditionally taken from the host system's available CPU features:...
> I know we create it, but I thought that "dummy" means that we don't use it later (except to just preserve the interface). Not true. We use the "dummy"...
> So, isn't this @Zebartin's bug here, not qemu's/gramine's? The token should be generated on the machine where you run the enclave, not where you build it. And I think...
Indeed, shrinking to arbitrary size is not implemented yet: https://github.com/gramineproject/gramine/blob/b822d29c971dc7e277c7f2d3f4b8dd219ccf29bd/common/src/protected_files/protected_files.c#L1219-L1220 I can imagine a naive way to implement it: 1. Read the encrypted file completely into a temporary buffer 2....
> Out of curiosity, how would you implement this to be performant? Well, just truncate the file using the host `ftruncate` to the required size. The problem with this approach...
> this truncat implemention would cause new problems(truncate just set file size,and keep file node as the old,instead of a new file)…… My proposal doesn't create a new file. All...
@lead4good Please try https://github.com/gramineproject/gramine/pull/972
Interesting performance numbers. Thanks for doing this effort @qijiax. 1. First, I would concentrate on the poor performance of `gramine-direct`. Already with 2 threads, its max achievable performance is `2395.46...
@qijiax The flame graphs show that there is indeed some problem with futexes (it is clearly seen on the last graph with 16 threads). However, these flame graphs do not...