Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LibOS] Add Recovery feature to Encrypted files #2013

Open
dimakuv opened this issue Oct 1, 2024 · 2 comments
Open

[LibOS] Add Recovery feature to Encrypted files #2013

dimakuv opened this issue Oct 1, 2024 · 2 comments

Comments

@dimakuv
Copy link

dimakuv commented Oct 1, 2024

Description of the feature

Intel SGX SDK's recovery code must be ported to Gramine. Kailun's team can work on this, but after the v1.8 release.

See #1972

Why Gramine should implement it?

Need recovery of partially-written files (before crash).

@dimakuv dimakuv moved this to Coming in next release (v1.8) in Gramine Roadmap Oct 1, 2024
@kailun-qin
Copy link
Contributor

Basically, SGX SDK's file recovery is implemented based on:

This "shadow" recovery file has a dump of the cached file blocks. Before we start to save the main file contents we will set the update_flag in the file's metadata node. It'll be cleared only when the transaction is over -- when the main file contents are fully dumped and the updated metadata node is written. If we open an encrypted file and find that the update_flag is set, we know that an error occured and a recovery process will start, and we will revert all the partial changes (the original data is in the recovery file) and return to the last known good state. Specifically:

@mkow
Copy link
Member

mkow commented Nov 5, 2024

Doesn't this make the I/O to encrypted files significantly slower?

@monavij monavij moved this from Working on it to Coming in next release (v1.9) in Gramine Roadmap Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Coming in next release (v1.9)
Development

No branches or pull requests

4 participants