[TDX] Alternatives for multi-processing support

[dimakuv]

Currently, Gramine-TDX does not support multi-processing. In other words, applications that try to fork or clone-new-process will fail to do so.

This significantly restricts the number of applications that can be run on Gramine-TDX. For example, almost all Bash and Busybox scripts require fork, and many Python workloads also require fork.

Also, Gramine's LibOS regression tests and LTP tests heavily rely on multi-processing. Without multi-processing support, only about ~20% of all tests can run, significantly reducing test coverage for Gramine's VM and TDX backends.

There are several alternatives what to do with multi-processing support:

1. Keep it as-is, i.e., no support. Pros: very simple design with a single flat ring-3/ring-0 address space, no need to track multiple page table hierarchies, no need to isolate Gramine's kernel data, no additional engineering effort. Cons: many apps won't run.
2. Implement multi-processing similarly to Gramine-SGX, i.e., create a new VM/TD for each new process. Pros: reuse design and implementation of Gramine-SGX, since creating new VM/TD is equivalent to creating a new SGX enclave. Checkpoint and restore logic, pipe encryption, parent-child attestation, and so on can all be reused as is, i.e., this would require reasonable engineering effort. Cons: very high memory, vCPU, and performance overhead, in comparison to classic multi-processing support (see option 3); also, it is a convoluted design that's hard to justify to users.
3. Implement multi-processing similarly to classic OS kernels, i.e., a single VM/TD hosts multiple processes. Pros: low memory, vCPU, and performance overhead; no need to encrypt pipes (as they are confined to a single VM/TD), simple to explain to users. Cons: goes against the philosophy and current implementation of Gramine, where each process runs in its own isolated environment (e.g., an SGX enclave). This would require significant engineering effort.