Add initrd feature flag to kernel, and expose stage0 dice data if it's set #4757
Conversation
At this point we imo need conditional compilation, because we want the kernel to behave quite differently based on whether it is loading an applicatino over the channel vs from the initrd. In the first case we want to create a new dice layer. In the second case we want to just expose the stage0 dice data to the orchestrator
|
I expect we'd get rid of the non-initrd method of loading the app completely at some point in the not too distant future. |
hopefully yeah. But I still think we should use compile time flags, especially now that the behavior is so different. The alternative is blocking deployments of binaries to google3 until we're finished (bad). Or executing different logic at runtime (no simpler, imo more potential for vulnerabilities). I think it's the right call for this, and also the dev workflow we should get familiar with for similiar changes in the future. One thing we could consider is to instead of gating initrd behind a feature, is moving the existing logic behind a default feature (and compiling initrd out if its set). |
At this point we imo need conditional compilation, because we want the kernel to behave quite differently based on whether it is loading an applicatino over the channel vs from the initrd.
In the first case we want to create a new dice layer. In the second case we want to just expose the stage0 dice data to the orchestrator