Peter Memishian wrote: > > This conversation got me thinking about the DLDIOC_DOORSERVER ioctl in UV > > used to set the door handle in the kernel based on a passed-in door fd. > > By the time this ioctl is processed by dld and dls calls > > door_ki_lookup(fd), how do we know that "fd" is valid? The > > door_ki_lookup() call eventually results in a getf(fd) call, and fd is > > looked-up in "curproc"... If the ioctl message was deferred and put on a > > queue, curproc won't be dlmgmtd, right? > > Yes, I think that's a problem. > > Off the top of my head, I see two options: > > 1. Do the getf() in the stream head. This goes against the > philosophy of STREAMS since the stream head is not supposed > to know anything about the ioctls that the modules or drivers > on it might accept. > > 2. Add agetf() (analogous to the existing areleasef()) that > allows one to lookup a file descriptor in a specific uf_info_t > other than the one tied to curproc, and then use DB_CPID(mp) > to find the process. This goes against the philosophy of > getf()/releasef() (areleasef() appears to be a wart) but > otherwise seems possible.
3. Invent a new set of syscalls to get and/or set the dlmgmtd door fd in dls... Some kernel modules seem to be using this method. Whichever method we use to fix this, we'll probably need to retrofit it into the other kernel doors implementations with similar bugs. From a quick inspection, this bug exists in the following existing ioctls in ON: * MD_MN_SET_DOORH * DRCTL_IOCTL_CONNECT_SERVER * SEV_SUBSCRIBE * SEV_UNSUBSCRIBE * CRYPTO_LOAD_DOOR -Seb
