linux
Nathaniel
Next is the Linux tree. And this is actually an interesting repo to talk about. So this is not Rust. And it's really the only non Rust code in the project. Although in a few places, we have some openSSL support for some stuff. But yeah, this is really the only non Rust code. So this is a Linux kernel tree. And it's actually multiple Linux kernel trees. The most important thing is the SGX and SNP branches. And this contains the kernels that we actually run on our lab machines. So let me describe the way that this actually works. So we actually have this branch called actions. And the very latest commit on this branch looks like this. And this is just GitHub actions, instructions on how to build a kernel. And what we do is we install all of the dependencies, then we use the existing Debian kernel configuration as a base, because we don't want to choose all the kernel parameters, we just want to use one that works, you know, pretty well for most situations. So then we want to make old config on that. In other words, we say we want to, you know, just basically have that configuration. And then and we pipe the output of Yes, with quotation marks into that, which allows us to say, if there's any new kernel features, since the Debian config, just accept the defaults, then we actually need to do the do the configuration again a second time. And the reason for that is that now that we've accepted all the defaults, we actually remove all of the AMD SEV and SGX related options from the config that we just generated, so that we will be able to be prompted for those again, and then we echo yes to make old config, so that we turn all of those options on, because otherwise they get turned off by default. So now that we have our kernel configured, we just basically run a build. And the most important bit is that we store the output of the build as an artifact in this tarball. And so if you actually look on the, let's look at the SGX branch. So this current SGX branch actually contains the upstream Linux kernel, plus a set of patches from Rene at Intel, enabling SGX 2, so these patches are not in the upstream Linux kernel and get, and then we cherry pick that previous commit we just looked at right on top. And when we push this branch, it causes GitHub actions to actually build the kernel. And so if we look at, if we go to GitHub actions, you can actually see, we've got kernel builds here or here. So if I go to SGX 1, for example, and then I can see the actual artifact here that was produced as part of the builds. And then we take this artifact, and we suck it into our lab machine configuration, and that's how it gets built. And so that whole process is automated, all you have to do is basically push the patches you want add that commit on top, and then everything just goes into a pipeline, and gets deployed into the lab machines from there. Ultimately, you know, we would like to merge these kernels. The the SNP and SGX kernels are currently separate, because the patches are against incompatible bases. But eventually, once they get closer to merging, we'll merge this all into one kernel. And then we'll just have one Enarx kernel and then eventually all the patches will be upstream and then we'll just have the upstream kernel.
No, they're completely different kernels. Yeah, the the reason for that is that Intel is developing the SGX patches against basically the latest. Its latest stable kernel. And the KVM branch uses the KVM maintainers' own tree as the development branch and the two branches are incompatible. The patches won't apply cleanly on either and we don't want to spend a lot of time to, you know, to rebase these patches because we know that they still need some pretty big changes. So yeah, this is really the only non Rust code in the project.
As soon as possible, because we really don't want to maintain this stuff. The SGX patches, I'm hoping will get upstream pretty quickly. They're pretty straightforward. And there's, yeah, Jarkko is the upstream kernel maintainer for SGX as well as other subsystems. So he's pretty confident that they can get through pretty quickly, because they're pretty obvious. And then we just basically have the SEV SNP stuff. It's really hard to tell right, kernel development is not always a linear process. However, AMD feels pretty confident that their guest patches will be upstream somewhat soon, and then the host patches will follow after that. The most important thing is that once the guest patches are upstream, then the host patches which we need, will actually get rebased on a much more modern kernel. And that will make our whole lives easier, particularly if SGX has also been merged. So hopefully it won't be terrible forever. But that's the situation.