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
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 schrieb am Mi., 2. Feb. 2022, 00:42:
> It
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
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
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 wrote:
> Hi Xiang, Hi Matthew,
>
> Thanks for your responses.
>
>
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
On Fri, Jan 28, 2022 at 7:43 PM Michael Jung 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
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 wrote:
> Hello everybody,
>
> I am developing a device driver, which is exposed as a character device
> (i.e. /dev/pcd) and which
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
