It seems to me that it is a security issue to permit an application to start kernel threads, albeit indirectly. Has anyone thought about this? Any user could bring the most protected system to its knees by causing many kernel threads to be generated.
On Sun, Jan 30, 2022 at 12:21 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > It's better to let kernel thread skip the duplication of caller's file > handler, here is the patch: > https://github.com/apache/incubator-nuttx/pull/5379 > Michael, could you try it? > > > On Mon, Jan 31, 2022 at 12:59 AM Michael Jung <mij...@gmx.net> wrote: > > > Hi Xiang, Hi Matthew, > > > > Thanks for your responses. > > > > Matthew wrote: > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > the file descriptors from the calling task to get copied. > > > > Yes, that is exactly what is happening. The started kernel thread > actively > > polls for an event to happen and terminates afterwards, calling close on > > all the copied file descriptors (which includes the one the ioctl was > > called on). Currently I made my device driver more robust via reference > > counting, but I tend to agree with the referenced issues that kernel > > threads should not maintain file descriptors. > > > > Thanks! > > Michael > > > > Am Fr., 28. Jan. 2022 um 23:38 Uhr schrieb Matthew Trescott < > > matthewtresc...@gmail.com>: > > > > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mij...@gmx.net> wrote: > > > > specific ioctl command implementation > > > > > > Creating a kernel thread in an ioctl "lower-half" would probably cause > > > the file descriptors from the calling task to get copied. Might this > > > be another case of > > > https://github.com/apache/incubator-nuttx/issues/1108 and > > > https://github.com/apache/incubator-nuttx/issues/2663 ? > > > > > >
