Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-06-04 23:03:27 +08:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Update TODO list.

Browse Source
This commit is contained in:
Gregory Nutt
2019-02-04 11:00:43 -06:00
parent 90e4cf4349
commit 05b85c8717
1 changed files with 34 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO
+34 -12
View File
@@ -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,