Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface

[Pratyush Yadav]

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