On Thu, Jul 17 2025, David Matlack wrote: > On Mon, Jul 14, 2025 at 7:56 AM Pratyush Yadav <pratyush@xxxxxxxxxx> wrote: >> On Thu, Jun 26 2025, David Matlack wrote: >> > On Thu, Jun 26, 2025 at 8:42 AM Pratyush Yadav <pratyush@xxxxxxxxxx> wrote: >> >> On Wed, Jun 25 2025, David Matlack wrote: >> >> > On Wed, Jun 25, 2025 at 2:36 AM Christian Brauner <brauner@xxxxxxxxxx> wrote: [...] >> >> Isn't giving back the right kexecfs instance to the right VMM the main >> problem? After a kexec, you need a way to make that policy decision. You >> would need a userspace agent to do that. >> >> I think what you are suggesting does make a lot of sense -- the agent >> should be handing out sessions instead of FDs, which would make FD >> save/restore simpler for applications. But that can be done using the >> ioctl interface as well. Each time you open() the /dev/liveupdate, you >> get a new session. Instead of file FDs like memfd or iommufs, we can >> have the agent hand out these session FDs and anything that was saved >> using this session would be ready for restoring. >> >> My main point is that this can be done with the current interface as >> well as kexecfs. I think there is very much a reason for considering >> kexecfs (like not being dependent on devtmpfs), but I don't think this >> is necessarily the main one. > > The main problem I'd like solved is requiring all FDs to preserved and > restored in the context of a central daemon, since I think this will > inevitably cause problems for KVM. I agree with you that this problem > can also be solved in other ways, such as session FDs (good idea!). Another benefit of session FDs: the central daemon can decide whether it wants to check each FD it gives over to a process, or just give over a session and let the process do whatever it wants. With the current patches, only the former operation model can be implemented. >> > >> > Policy can be enforced by controlling access to kexecfs mounts. This >> > naturally fits into the standard architecture of running untrusted VMs >> > (e.g. using chroots and containers to enforce security and isolation). >> >> How? After a kexec, how do you tell which process can get which kexecfs >> mount/instance? If any of them can get any, then we lose all sort of >> policy enforcement. > > I was imagining it's up to whatever process/daemon creates the kexecfs > instances before kexec is also responsible for reassociating them with > the right processes after kexec. > > If you are asking how that association would be done mechanically, I > was imagining it would be through a combination of filesystem > permissions, mounts, and chroots. For example, the kexecfs instance > for VM A would be mounted in VM A's chroot. VM A would then only have > access to its own kexecfs instance. Hmm, good point. This would be quite a clean way of doing it I think. [...] -- Regards, Pratyush Yadav
