How to upgrade app and keep old encrypted data?
Seems https://github.com/occlum/occlum/issues/1311#issuecomment-1588879195 doesn't work in Occlum 0.29.6. After rebuild occlum instance by using "occlum build" or using "occlum build -f", old encrypted data is lost. Even backup the old encrypted data( ./run/mount/__ROOT ?), and restore to the new upgraded Occlum instance. Occlum start always fail with error:
Error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" } [ERROR] occlum-pal: The init process exit with code: 1 (line 63, file src/pal_api.c) [ERROR] occlum-pal: Failed to run the init process: EINVAL (line 151, file src/pal_api.c) Error: -1 start server failed Failed to launch server
How to upgrade the Occlum app and keep old encrypted data?
@enuoCM Please try 0.29.7 which fixes the issue.
0.29.7 still has this issue.
[2023-09-08T08:55:12.518Z][ERROR][T1][#44][MountRootFS] Error = EINVAL (#22, Invalid argument): WrongFs Error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" } [ERROR] occlum-pal: The init process exit with code: 1 (line 63, file src/pal_api.c) [ERROR] occlum-pal: Failed to run the init process: EINVAL (line 151, file src/pal_api.c)
BTW "external mount" is ok now. Old external mounted encrypted data can be accessed by the upgrade app.
@qzheng527 Occlum server can start if just restore ./run/initfs/__ROOT on 0.29.7, but lost old encrypted data. And I tried this on 0.29.5, restore ./run/initfs/__ROOT, ./run/mount/__ROOT or both, occlum can not start with different error:
thread '<unnamed>' panicked at 'explicit panic', src/fs/rootfs.rs:28:13
@qzheng527 @liqinggd The root cause is that: the container fs (old encrypted data) kept the mac of the image fs(old app data), after upgraded the app, the mac of image fs(new app data) changed. When creating the new UnionFS with the new image fs and old container fs, it can not pass the UnionFS#new#verify_with_mac_file. Why do we need this checking?
@enuoCM If you want to keep the old encrypted data, just put the data in an external mount path instead of the default run path. The reason of not supporting reuse of the old encrypted data is due to security concern. Just imagine, if a hacker can rebuild the app plus keeping the old encrypted data, then there is no secret anymore.
@enuoCM If you want to keep the old encrypted data, just put the data in an external mount path instead of the default run path. The reason of not supporting reuse of the old encrypted data is due to security concern. Just imagine, if a hacker can rebuild the app plus keeping the old encrypted data, then there is no secret anymore.
If to use an external mount path, such as source: /external, target: /app-data, app has to write data to the specific /app-data path to persist. Other data want to be kept but not write to the /app-data, will go to the run path, which may be removed or can not be used anymore after app upgraded. This is a little weird. And we can not modify some 3rd apps' behavior.
As for the safety considerations, if a hacker can rebuild the app, he can backup the run path data before rebuilding. There is no difference between external and run path encrypted data.