You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Michael Jung <mi...@gmx.net> on 2022/01/28 11:42:40 UTC
Right way to start a lightweight kernel thread without copying open file descriptors?
Hello everybody,
I am developing a device driver, which is exposed as a character device
(i.e. /dev/pcd) and which mostly uses ioctl for device control. Within a
specific ioctl command implementation I am starting a new kernel thread via
kthread_create_with_stack. Once this thread's main function exits, the
NuttX scheduler calls 'close' on all open file descriptors, which causes
undesired side effects.
What is the correct way to start a lightweight kernel thread without
copying the open file descriptors from the original thread? (workqueues are
probably not an option since the thread's main function might run for an
extended period of time).
Your help is much appreciated
Thanks!
Michael
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Michael Jung <mi...@gmx.net>.
Hello Xiang,
you wrote:
> Michael, could you try it?
Sorry for the delayed response. I was away from my computer for some time.
I realized that the fix already went upstream. I tested the current tip of
the master branch and the fix works fine for me.
Thanks a lot for your help,
Michael
Am So., 30. Jan. 2022 um 19:21 Uhr schrieb Xiang Xiao <
xiaoxiang781216@gmail.com>:
> 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 <mi...@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 <
> > matthewtrescott@gmail.com>:
> >
> > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
> > >
> >
>
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Gregory Nutt <sp...@gmail.com>.
in my case the device driver keeps track whether the kernel thread runs and
> returns EBUSY If thats the case for a second start attempt. Would that be
> sufficient to avoid the security risk you are considering?
>
>
Yes. A more typical use case would be to start the kernel thread at the
time that the driver is initialized.
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Michael Jung <mi...@gmx.net>.
Hi Greg,
in my case the device driver keeps track whether the kernel thread runs and
returns EBUSY If thats the case for a second start attempt. Would that be
sufficient to avoid the security risk you are considering?
Thanks!
Michael
Gregory Nutt <sp...@gmail.com> schrieb am Mi., 2. Feb. 2022, 00:42:
> 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 <xi...@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 <mi...@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 <
> > > matthewtrescott@gmail.com>:
> > >
> > > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
> > > >
> > >
> >
>
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Gregory Nutt <sp...@gmail.com>.
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 <xi...@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 <mi...@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 <
> > matthewtrescott@gmail.com>:
> >
> > > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
> > >
> >
>
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Xiang Xiao <xi...@gmail.com>.
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 <mi...@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 <
> matthewtrescott@gmail.com>:
>
> > On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
> >
>
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Michael Jung <mi...@gmx.net>.
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 <
matthewtrescott@gmail.com>:
> On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
>
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Matthew Trescott <ma...@gmail.com>.
On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@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 ?
Re: Right way to start a lightweight kernel thread without copying open file descriptors?
Posted by Xiang Xiao <xi...@gmail.com>.
In the kernel, you should call file_open(file_close...)
instead open(close...) to avoid the problem you described below.
On Fri, Jan 28, 2022 at 7:43 PM Michael Jung <mi...@gmx.net> wrote:
> Hello everybody,
>
> I am developing a device driver, which is exposed as a character device
> (i.e. /dev/pcd) and which mostly uses ioctl for device control. Within a
> specific ioctl command implementation I am starting a new kernel thread via
> kthread_create_with_stack. Once this thread's main function exits, the
> NuttX scheduler calls 'close' on all open file descriptors, which causes
> undesired side effects.
>
> What is the correct way to start a lightweight kernel thread without
> copying the open file descriptors from the original thread? (workqueues are
> probably not an option since the thread's main function might run for an
> extended period of time).
>
> Your help is much appreciated
>
> Thanks!
> Michael
>