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

[Pasha Tatashin]

On Wed, May 28, 2025 at 4:29 PM David Matlack <dmatlack@xxxxxxxxxx> wrote:
>
> On Thu, May 15, 2025 at 11:23 AM Pasha Tatashin
> <pasha.tatashin@xxxxxxxxxx> wrote:
> > +static int luo_open(struct inode *inodep, struct file *filep)
> > +{
> > +       if (!capable(CAP_SYS_ADMIN))
> > +               return -EACCES;
>
> It makes sense that LIVEUPDATE_IOCTL_EVENT* would require
> CAP_SYS_ADMIN. But I think requiring it for LIVEUPDATE_IOCTL_FD* will
> add a lot of complexity.
> It would essentially require a central userspace process to mediate
> all preserving/restoring of file descriptors across Live Update to
> enforce security. If we need a central authority to enforce security,
> I don't see why that authority can't just be the kernel or what the
> industry gains by punting the problem to userspace. It seems like all
> users of LUO are going to want the same security guarantees when it
> comes to FDs: a FD preserved inside a given "security domain" should
> not be accessible outside that domain.
>
> One way to do this in the kernel would be to have the kernel hand out
> Live Update security tokens (say, some large random number). Then
> require userspace to pass in a security token when preserving an FD.
> Userspace can then only restore or unpreserve an FD if it passes back
> in the security token associated with the FD. Then it's just up to
> each userspace process to remember their token across kexec, keep it
> secret from other untrusted processes, and pass it back in when
> recovering FDs.
>
> All the kernel has to do is generate secure tokens, which I imagine
> can't be that hard.

Based on current discussions at the bi-weekly hypervisor live update
sync [1], one proposed idea is for LIVEUPDATE_IOCTL_FD_* operations to
be managed by a dedicated userspace agent. This agent would be
responsible for preserving and restoring file descriptors,
subsequently passing them to their respective owners (e.g., VMMs).
While the complexity of implementing such a userspace architecture in
a cloud environment is unclear to me, introducing kernel-enforced
security boundaries around /dev/liveupdate tokens themselves (instead
of CAP_SYS_ADMIN for the device node) seems too complex and
potentially risky to incorporate at this stage of LUO's development.
If finer-grained, token-based security is necessary, it could perhaps
be an optional extension to LUO in the future managed by a dedicated
CONFIG_*.

[1] https://lore.kernel.org/all/958b2ec3-f5f1-b714-1256-1b06dcf7470f@xxxxxxxxxx/