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

Feature: Reconstruct our Buildroot image to follow Google Hardened Image #264

Open
drasko opened this issue Sep 26, 2024 · 4 comments
Open
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@drasko
Copy link
Contributor

drasko commented Sep 26, 2024

Is your feature request related to a problem? Please describe.

No

Describe the feature you are requesting, as well as the possible use case(s) for it.

We should save RAM only for execution (as it is limited). All other artifacts (Linux files, algrotihm, Agent and other binaries, downloaded Docker images, Pytorch libraries, etc...) should live on disk.

Google proposes following: https://cloud.google.com/docs/security/confidential-space

  1. Root FS - probably ext4 - OS artifacts on the disk, including Agent. This one should be immutable (read-only) - no one should ever change Agent or OS files.
  2. Mutable (read-write) disk partition, but this one then must be encrypted, as it will contain downloaded Docker images or algorithm binaries and potentially also datasets. Result can be written there.
  3. tmpfs - this is the one in which execution must be done, so that we guarantee that it is in RAM.

An additional research needs to be done on this, but those changes make sense in order to better optimize RAM usage and protect Agent and other artifacts further (immutable partition), protect downloaded algo (when not put in RAM - foroptimization - Docker image needs to we written in encrypted mutable partition) and result, and ensure execution in tmpfs without swap.

Indicate the importance of this feature to you.

Must-have

Anything else?

No response

@drasko
Copy link
Contributor Author

drasko commented Sep 30, 2024

@danko-miladinovic @SammyOina @rodneyosodo can you please verify this:

image

If this is true, and it is like this for Intel TDX also, then we do not have to disable swap. Moreover - we should enable swap and use it, in order to preserve RAM.

@danko-miladinovic
Copy link
Contributor

Yes, based on the paper SEV-SNP formal security analysis the pages are encrypted when they are swapped to disk.

@dborovcanin dborovcanin added enhancement New feature or request question Further information is requested labels Oct 8, 2024
@dborovcanin
Copy link
Contributor

@drasko What are the benefits of this approach? We need to put most of it into RAM to make it run anyway, and adding disk support is quite a significant change that requires disk encryption. @danko-miladinovic I don't think we are talking about process pages, but everything else that is not part of the process, but the system.

@drasko
Copy link
Contributor Author

drasko commented Oct 8, 2024

There are many benefits. For example swap. Then - Linux system can be on RO unencrypted (no jeed to put everything in RAM). And so on. Also big data files that can be treated one by one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

5 participants