lejunzhu

> To be honest, I didn't understand Borys's idea. (As Michal mentioned, 1 is a risky assumption so we could go with 2, but I don't really understand 2. Sounds...

But if the application is not specifically modified for Gramine, it may refuse to run if the file is r/o. Then the data will be lost if it is encrypted...

> That is true. The alternative will be to allow writes as well, and print a warning (or have a manifest option like `sgx.allow_old_files` which is false by default). But...

> MRENCLAVE is subject to change per build regardless of this issue. In general, if you need data to persist across different versions, you should use MRSIGNER-based keys I'm thinking...

A single, oldest CPUSVN is probably not desirable. When there is a security update, the old keys are potentially compromised. If we keep using the old keys to encrypt new...

> * Migration of the file to the new key is done in a dumb way -- simply re-encrypt the whole file contents by first decrypting with the old key,...

> Looks good from my side, although I only did a quick read. One important problem here is that it doesn't give the user any practical way to upgrade the...

> @lejunzhu `nfds` can be arbitrarily large. You are right, I forgot this. > The `SOME_MAX_LIMIT` macro should be chosen such that we don't consume more than e.g. 64KB-128KB of...

> 1K sounds way to much for a stack buffer Do you mean a lower threshold, e.g. 320 bytes for each buffer is acceptable, or this problem should better be...

I've created a PR #1051 to reduce the lock contention in poll. @dimakuv and @boryspoplawski would you please take a look at it? @lianghouxu would you please to test this...