occlum icon indicating copy to clipboard operation
occlum copied to clipboard

How to upgrade app and keep old encrypted data?

Open enuoCM opened this issue 2 years ago • 6 comments

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 avatar Sep 07 '23 09:09 enuoCM

@enuoCM Please try 0.29.7 which fixes the issue.

qzheng527 avatar Sep 07 '23 09:09 qzheng527

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.

enuoCM avatar Sep 08 '23 03:09 enuoCM

@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

enuoCM avatar Sep 11 '23 07:09 enuoCM

@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 avatar Sep 20 '23 06:09 enuoCM

@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.

qzheng527 avatar Sep 20 '23 07:09 qzheng527

@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.

enuoCM avatar Sep 20 '23 08:09 enuoCM