Hi,

i meant that, if userspace wants to read some kernel memory, it can pass
the kernel pointer to eg. write system call as the buffer argument,
and then read the contents of the file.
I guess I still don't understand.  Access is still via file descriptor.
You could certainly clobber kernel memory with a read in that way.  But
it is not clear how you could read the kernel memory into user space.
Here is an example:
Program open malicious elf and call read with a pointer to kernel
stack, then kernel may run code from elf after kernel finish and
return.

It is not clear to me how you could do that.  The stack is not accessible to the calling thread while the system call is running, but I suppose it could be accessed by another thread:

1. Thread A calls sem wait
2. Thread B modifies Thread A return stack so that sem_wait returns to user code, then posts the semaphoe
3. When semaphore wakes up, the return would execute in supervisor mode.

Unlike Linux (and most higher end OS's), NuttX does not use a separate kernel stack.  In Linux, each task has two stacks, a user space stack and a kernel space stack.  In the system call handler, it switches ti the kernel stack; on the system call return, it switches back to the user stack.  That allows you to protect the stack from any user access while in kernelmode and would prohibit this kind of thing.


my question was if these kinds of checks were for some reasons considered
unnecessary for nuttx.
At this point, there were never considered at all.  Whenever I find
security issues in PROTECTED builds, I add that to the TODO list (if I
don't fix them).

I think that most syscall which contain pointer has the security issue
in PROTECTED/KERNEL mode.

Certainly if high security is need, they all should be reviewed. Linux goes to a lot of trouble to access data pointed to by user-provided pointers. We might need to add all of those access macros in the future.

KERNEL mode is a little more complex in that you also have to assure that the correct MMU mappings are in place before to access user data from a different kernel thread (like a work queue).

Greg


Reply via email to