mirror of
https://github.com/apache/nuttx.git
synced 2026-06-04 23:03:27 +08:00
Update TODO list.
This commit is contained in:
@@ -13,7 +13,7 @@ nuttx/:
|
|||||||
(5) SMP
|
(5) SMP
|
||||||
(1) Memory Management (mm/)
|
(1) Memory Management (mm/)
|
||||||
(0) Power Management (drivers/pm)
|
(0) Power Management (drivers/pm)
|
||||||
(4) Signals (sched/signal, arch/)
|
(5) Signals (sched/signal, arch/)
|
||||||
(2) pthreads (sched/pthread)
|
(2) pthreads (sched/pthread)
|
||||||
(0) Message Queues (sched/mqueue)
|
(0) Message Queues (sched/mqueue)
|
||||||
(10) Kernel/Protected Build
|
(10) Kernel/Protected Build
|
||||||
@@ -779,6 +779,27 @@ o Signals (sched/signal, arch/)
|
|||||||
complained about it. Apparently the visibility of the problem is
|
complained about it. Apparently the visibility of the problem is
|
||||||
very low.
|
very low.
|
||||||
|
|
||||||
|
Title: QUEUED SIGNAL ACTIONS ARE INAPPROPRIATELY DEFERRED
|
||||||
|
Descirption: The implement of nxsig_deliver() does the followin in a loop:
|
||||||
|
- It takes the next next queued signal action from a list
|
||||||
|
- Calls the architecture-specific up_sigdeliver() to perform
|
||||||
|
the signal action (through some sleight of hand in
|
||||||
|
up_schedule_sigaction())
|
||||||
|
- up_sigdeliver() is a trampoline function that performs the
|
||||||
|
actual signal action as well as some housekeeping functions
|
||||||
|
then
|
||||||
|
- up_sigdeliver() performs a context switch back to the normal,
|
||||||
|
uninterrupted thread.
|
||||||
|
|
||||||
|
The loop in nxsig_deliver() then will have the opportunity to
|
||||||
|
run until when that normal, uniterrupted thread is suspended.
|
||||||
|
Then the loop will continue with the next queued signal
|
||||||
|
action.
|
||||||
|
Status: Open
|
||||||
|
Priority: Low. This design flaw has been around for ages and no one has yet
|
||||||
|
complained about it. Apparently the visibility of the problem is
|
||||||
|
very low.
|
||||||
|
|
||||||
o pthreads (sched/pthreads)
|
o pthreads (sched/pthreads)
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
@@ -1076,10 +1097,10 @@ o Kernel/Protected Build
|
|||||||
performance implications if the the errno variable is accessed
|
performance implications if the the errno variable is accessed
|
||||||
via a system call at high rates.
|
via a system call at high rates.
|
||||||
|
|
||||||
Title: SIGNAL DELIVERY VULNERABILITY
|
Title: SIGNAL ACTION VULNERABILITY
|
||||||
Description: When a signal is delivered, the user stack is used. Unlike
|
Description: When a signal action is peformed, the user stack is used.
|
||||||
Linux, applications do not have separate user and supervisor
|
Unlike Linux, applications do not have separate user and
|
||||||
stacks; everything is done on the user stack.
|
supervisor stacks; everything is done on the user stack.
|
||||||
|
|
||||||
In the implementation of up_sigdeliver(), a copy of the
|
In the implementation of up_sigdeliver(), a copy of the
|
||||||
register contents that will be restored is present on the
|
register contents that will be restored is present on the
|
||||||
@@ -1088,17 +1109,18 @@ o Kernel/Protected Build
|
|||||||
occur when the user task returns to supervisor mode from
|
occur when the user task returns to supervisor mode from
|
||||||
the the signal handler.
|
the the signal handler.
|
||||||
|
|
||||||
A recent commit (4 Feb 2019) does protect the status register
|
A recent commit (3 Feb 2019) does protect the status register
|
||||||
and return address so that a malicious task cannot change the
|
and return address so that a malicious task cannot change the
|
||||||
return address and switch to supervisor mode. Other register
|
return address or switch to supervisor mode. Other register
|
||||||
are still modifiable and there is other possible mayhem that
|
are still modifiable so there is other possible mayhem that
|
||||||
could be done.
|
could be done.
|
||||||
|
|
||||||
A better solution, in lieu of a kernel stack, would be to
|
A better solution, in lieu of a kernel stack, would be to
|
||||||
eliminate the stack-based register save area and, instead,
|
eliminate the stack-based register save area altogether and,
|
||||||
save the registers in another, dedicated state save area in
|
instead, save the registers in another, dedicated state save
|
||||||
the TCB. The only hesitation to this option is that it would
|
area in the TCB. The only hesitation to this option is that
|
||||||
significantly increase the size of the TCB structure.
|
it would significantly increase the size of the TCB structure
|
||||||
|
and, hence, the per-thread memory overhead.
|
||||||
Status: Open
|
Status: Open
|
||||||
Priority: Medium-ish if are attempting to make a secure environment that
|
Priority: Medium-ish if are attempting to make a secure environment that
|
||||||
may host malicious code. Very low for the typical FLAT build,
|
may host malicious code. Very low for the typical FLAT build,
|
||||||
|
|||||||
Reference in New Issue
Block a user