Re: how to build userspace for CONFIG_BUILD_KERNEL
On Wed, Feb 26, 2020 at 12:57 PM Takashi Yamamoto wrote: > > hi, > > On Wed, Feb 26, 2020 at 1:36 PM Xiang Xiao wrote: > > > > For kernel build, all symbols need be resolved: > > 1.We need add libapps.a into LDLIBS to resolve nsh_*, which remove > > accidentally in commit 4ee39e208048f075860 > > it removed only "ifneq ($(CONFIG_BUILD_KERNEL),y)" block. > it should not affect KERNEL build, should it? > After review the related Makefile again, I think we need remove "ifneq ($(CONFIG_BUILD_KERNEL),y)", LDLIBS should contain libapps.a for both mode. > > 2.LDLIBS should contain libproxy.a to resolve sched_*, and libc.a for > > fprintf, but these library should in LDLIBS automatically. > > > > Thanks > > Xiang > > > > On Wed, Feb 26, 2020 at 11:23 AM Takashi Yamamoto > > wrote: > > > > > > hi, > > > > > > how can i build userspace for CONFIG_BUILD_KERNEL? > > > > > > using sama5d4-ek:knsh config, > > > i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". > > > it generated some binaries like the following. > > > but i don't see how it will get nsh_consolemain etc. > > > > > > spacetanuki% nm ../apps/bin/init > > > 00c0 B _ebss > > > 00c0 D _edata > > > 00c0 N _edtors > > > 00c0 N _enoinit > > > 00bf R _erodata > > > 0098 T _etext > > > 00c0 B _sbss > > > 00c0 N _sctors > > > 00bf D _sdata > > > 00c0 N _sdtors > > > 00c0 N _snoinit > > > 0098 R _srodata > > > T _stext > > > U fprintf > > > T main > > > U nsh_consolemain > > > U nsh_initialize > > > U sched_getparam > > > U sched_getstreams > > > U sched_setparam > > > spacetanuki%
Re: how to build userspace for CONFIG_BUILD_KERNEL
hi, On Wed, Feb 26, 2020 at 1:36 PM Xiang Xiao wrote: > > For kernel build, all symbols need be resolved: > 1.We need add libapps.a into LDLIBS to resolve nsh_*, which remove > accidentally in commit 4ee39e208048f075860 it removed only "ifneq ($(CONFIG_BUILD_KERNEL),y)" block. it should not affect KERNEL build, should it? > 2.LDLIBS should contain libproxy.a to resolve sched_*, and libc.a for > fprintf, but these library should in LDLIBS automatically. > > Thanks > Xiang > > On Wed, Feb 26, 2020 at 11:23 AM Takashi Yamamoto > wrote: > > > > hi, > > > > how can i build userspace for CONFIG_BUILD_KERNEL? > > > > using sama5d4-ek:knsh config, > > i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". > > it generated some binaries like the following. > > but i don't see how it will get nsh_consolemain etc. > > > > spacetanuki% nm ../apps/bin/init > > 00c0 B _ebss > > 00c0 D _edata > > 00c0 N _edtors > > 00c0 N _enoinit > > 00bf R _erodata > > 0098 T _etext > > 00c0 B _sbss > > 00c0 N _sctors > > 00bf D _sdata > > 00c0 N _sdtors > > 00c0 N _snoinit > > 0098 R _srodata > > T _stext > > U fprintf > > T main > > U nsh_consolemain > > U nsh_initialize > > U sched_getparam > > U sched_getstreams > > U sched_setparam > > spacetanuki%
Re: how to build userspace for CONFIG_BUILD_KERNEL
For kernel build, all symbols need be resolved: 1.We need add libapps.a into LDLIBS to resolve nsh_*, which remove accidentally in commit 4ee39e208048f075860 2.LDLIBS should contain libproxy.a to resolve sched_*, and libc.a for fprintf, but these library should in LDLIBS automatically. Thanks Xiang On Wed, Feb 26, 2020 at 11:23 AM Takashi Yamamoto wrote: > > hi, > > how can i build userspace for CONFIG_BUILD_KERNEL? > > using sama5d4-ek:knsh config, > i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". > it generated some binaries like the following. > but i don't see how it will get nsh_consolemain etc. > > spacetanuki% nm ../apps/bin/init > 00c0 B _ebss > 00c0 D _edata > 00c0 N _edtors > 00c0 N _enoinit > 00bf R _erodata > 0098 T _etext > 00c0 B _sbss > 00c0 N _sctors > 00bf D _sdata > 00c0 N _sdtors > 00c0 N _snoinit > 0098 R _srodata > T _stext > U fprintf > T main > U nsh_consolemain > U nsh_initialize > U sched_getparam > U sched_getstreams > U sched_setparam > spacetanuki%
[GitHub] [incubator-nuttx-testing] liuguo09 opened a new pull request #9: fulllist: remove sim:mtdpart and sim:mtdrwb configs
liuguo09 opened a new pull request #9: fulllist: remove sim:mtdpart and sim:mtdrwb configs URL: https://github.com/apache/incubator-nuttx-testing/pull/9 Remove sim:mtdpart and sim:mtdrwb configs since i386 libz not available now in Apache Jenkins slaves. Revert this change once i386 libz installed. Build error logs: /usr/bin/ld: skipping incompatible //usr/lib/x86_64-linux-gnu/libz.so when searching for -lz /usr/bin/ld: skipping incompatible //usr/lib/x86_64-linux-gnu/libz.a when searching for -lz /usr/bin/ld: cannot find -lz collect2: error: ld returned 1 exit status Signed-off-by: liuhaitao This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: how to build userspace for CONFIG_BUILD_KERNEL
Hi, There are some instructions for it used to be done here: https://github.com/apache/incubator-nuttx/blob/master/boards/arm/sama5/sama5d4-ek/README.txt#L4018 However, a lot has changed in the apps/ build so you will probably need to get updates from Xiao Xiang. Those instructions were valid up to a couple of years ago. But probably not now. Getting updated instructions there would be a great thing. A PR to do that would be welcome! Greg On 2/25/2020 9:18 PM, Takashi Yamamoto wrote: hi, how can i build userspace for CONFIG_BUILD_KERNEL? using sama5d4-ek:knsh config, i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". it generated some binaries like the following. but i don't see how it will get nsh_consolemain etc. spacetanuki% nm ../apps/bin/init 00c0 B _ebss 00c0 D _edata 00c0 N _edtors 00c0 N _enoinit 00bf R _erodata 0098 T _etext 00c0 B _sbss 00c0 N _sctors 00bf D _sdata 00c0 N _sdtors 00c0 N _snoinit 0098 R _srodata T _stext U fprintf T main U nsh_consolemain U nsh_initialize U sched_getparam U sched_getstreams U sched_setparam spacetanuki%
how to build userspace for CONFIG_BUILD_KERNEL
hi, how can i build userspace for CONFIG_BUILD_KERNEL? using sama5d4-ek:knsh config, i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". it generated some binaries like the following. but i don't see how it will get nsh_consolemain etc. spacetanuki% nm ../apps/bin/init 00c0 B _ebss 00c0 D _edata 00c0 N _edtors 00c0 N _enoinit 00bf R _erodata 0098 T _etext 00c0 B _sbss 00c0 N _sctors 00bf D _sdata 00c0 N _sdtors 00c0 N _snoinit 0098 R _srodata T _stext U fprintf T main U nsh_consolemain U nsh_initialize U sched_getparam U sched_getstreams U sched_setparam spacetanuki%
Podling Nuttx Report Reminder - March 2020
Dear podling, This email was sent by an automated system on behalf of the Apache Incubator PMC. It is an initial reminder to give you plenty of time to prepare your quarterly board report. The board meeting is scheduled for Wed, 18 March 2020, 10:30 am PDT. The report for your podling will form a part of the Incubator PMC report. The Incubator PMC requires your report to be submitted 2 weeks before the board meeting, to allow sufficient time for review and submission (Wed, March 04). Please submit your report with sufficient time to allow the Incubator PMC, and subsequently board members to review and digest. Again, the very latest you should submit your report is 2 weeks prior to the board meeting. Candidate names should not be made public before people are actually elected, so please do not include the names of potential committers or PPMC members in your report. Thanks, The Apache Incubator PMC Submitting your Report -- Your report should contain the following: * Your project name * A brief description of your project, which assumes no knowledge of the project or necessarily of its field * A list of the three most important issues to address in the move towards graduation. * Any issues that the Incubator PMC or ASF Board might wish/need to be aware of * How has the community developed since the last report * How has the project developed since the last report. * How does the podling rate their own maturity. This should be appended to the Incubator Wiki page at: https://cwiki.apache.org/confluence/display/INCUBATOR/March2020 Note: This is manually populated. You may need to wait a little before this page is created from a template. Note: The format of the report has changed to use markdown. Mentors --- Mentors should review reports for their project(s) and sign them off on the Incubator wiki page. Signing off reports shows that you are following the project - projects that are not signed may raise alarms for the Incubator PMC. Incubator PMC
Re: [PATCH] fix memset() implicit declaration warning
On Tue, Feb 25, 2020 at 1:15 PM Gregory Nutt wrote: > > > > Commit 1f1356a2f5ee91ae077038c9e7b7a8fccc4180b8 introduces a compiler > > warning. > > > > The fix is simple: Include in net/icmp/icmp_input.c. > > > > Something is broken at GitHub (or my GitHub account, or my > > incubator-nuttx fork, or something). Therefore I am sending a patch > > instead of a pull request. > > > > Patch attached... > > yes.. something is broken: https://www.githubstatus.com/ How lovely.
Re: [PATCH] fix memset() implicit declaration warning
Commit 1f1356a2f5ee91ae077038c9e7b7a8fccc4180b8 introduces a compiler warning. The fix is simple: Include in net/icmp/icmp_input.c. Something is broken at GitHub (or my GitHub account, or my incubator-nuttx fork, or something). Therefore I am sending a patch instead of a pull request. Patch attached... yes.. something is broken: https://www.githubstatus.com/
[PATCH] fix memset() implicit declaration warning
Commit 1f1356a2f5ee91ae077038c9e7b7a8fccc4180b8 introduces a compiler warning. The fix is simple: Include in net/icmp/icmp_input.c. Something is broken at GitHub (or my GitHub account, or my incubator-nuttx fork, or something). Therefore I am sending a patch instead of a pull request. Patch attached... Cheers, Nathan From 2ba54345a0a2df6ecc8a22dc5fc866ab7fdf634e Mon Sep 17 00:00:00 2001 From: Nathan Hartman Date: Tue, 25 Feb 2020 13:10:43 -0500 Subject: [PATCH] net/icmp/icmp_input.c: Fix memset() implicit decl warning --- net/icmp/icmp_input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/icmp/icmp_input.c b/net/icmp/icmp_input.c index 1c9bf88bad..a184bdfe82 100644 --- a/net/icmp/icmp_input.c +++ b/net/icmp/icmp_input.c @@ -47,6 +47,7 @@ #ifdef CONFIG_NET #include +#include #include #include -- 2.20.1
Re: userspace/kernel isolation question
"During system calls, the user mode thread’s access to the system call and the *passed-in parameters are all validated*. I think this is a fine thing to do and would welcome such checks into the OS. We would have to be careful. In the case of read(), for example: ssize_t read(int fd, FAR void *buf, size_t nbytes); The read logic is also used by the OS internally, so the check would have to implemented such that the kernel can still modify kernel memory. But that is pretty easy: The kernel does not use read() directly. The kernel will use nx_read() or, more likely file_read(). So only uset code would actually call read(). read() is just a stub around nx_read() that handles cancellation points and sets the errno value. So it would be the perfect place to add a check if the 'buf' resides in kernel memory. If so, return error. Greg
Re: userspace/kernel isolation question
But stub call into the real and complex implementation and then the kernel stack will contain many return address point, the hack can command kernel write what he want into this region and modify some return address point to that region, then the kernel will jump to the code eventually. That is possible so I am sure that someout out there could be diligent enought to make it happen. There are several chicken'n' egg problems in doing it as you describe.
Re: userspace/kernel isolation question
On Wed, Feb 26, 2020 at 12:34 AM Gregory Nutt wrote: > > On 2/25/2020 10:26 AM, Xiang Xiao wrote: > > On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote: > >> 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. > >> > > Since all arch need save the function return address into stack > > eventually, if userspace pass a pointer inside the stack and request > > kernel read the file provided by userspace to this pointer, then > > kernel may get the wrong return address and run the malicious code > > with the highest privilege. The keypoint isn't whether we use > > two(user/kernel) stack or single stack, but the kernel may corrupt the > > return address saved in the stack and then jump to the attacked code > > before low the privilege. > > yes, I think you could do that in the current environment, but I don't > think it would be possible to do that with two stacks -- well, at least > if would not be easy. The kernel logic invoked by the syscall code does > not "return" using any stack data. It executes a second system call > without returning (SYS_syscall_return). The second system call performs > the return to user space. There might be some way to hack into that, > but just ovewriting the return address on the kernel stack won't do it. > > But stub call into the real and complex implementation and then the kernel stack will contain many return address point, the hack can command kernel write what he want into this region and modify some return address point to that region, then the kernel will jump to the code eventually.
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 5:27 PM Gregory Nutt wrote: > > > ... How are syscalls dealt in other RTOS using MPU? > > For the case of the MPU, there is no general answer to that. I don't > think that there is any standard model for the use of the MPU in a > Unix-like system. > > NuttX uses the MPU to create a Kernel space with the OS and critical > board logic in it and a separate user space for applications. That is > inspired by the standard Unix kernel + applications model. > > But every use of the MPU that I am familiar with in deeply embedded > bare-metal or tiny RTOS systems are totally custom solutions. > > For the MMU (which you might think of as an MPU with address mapping), > the Unix model is the only one I am familiar with. As in Linux, a > kernel blob and applications loaded into RAM from a file system. > > Greg > > Thanks for the info. I did a quick search and find some examples: *Zephyr*: https://docs.zephyrproject.org/1.13.0/kernel/usermode/mpu_userspace.html (emphasis added by me): "During system calls, the user mode thread’s access to the system call and the *passed-in parameters are all validated*. The user mode thread is then elevated to privileged mode, the stack is switched to use the privileged stack, and the call is made to the specified kernel API. On return from the kernel API, the thread is set back to user mode and the stack is restored to the user stack." Not sure what kind of validation is done though. *FreeRTOS*: some documentation related to MPU memory regions (but nothing said about syscall params): https://freertos.org/FreeRTOS-MPU-memory-protection-unit.html I would like to check the code, but if someone already know about it would be great :) Cheers, Miguel
Re: userspace/kernel isolation question
On 2/25/2020 10:26 AM, Xiang Xiao wrote: On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote: 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. Since all arch need save the function return address into stack eventually, if userspace pass a pointer inside the stack and request kernel read the file provided by userspace to this pointer, then kernel may get the wrong return address and run the malicious code with the highest privilege. The keypoint isn't whether we use two(user/kernel) stack or single stack, but the kernel may corrupt the return address saved in the stack and then jump to the attacked code before low the privilege. yes, I think you could do that in the current environment, but I don't think it would be possible to do that with two stacks -- well, at least if would not be easy. The kernel logic invoked by the syscall code does not "return" using any stack data. It executes a second system call without returning (SYS_syscall_return). The second system call performs the return to user space. There might be some way to hack into that, but just ovewriting the return address on the kernel stack won't do it.
Re: userspace/kernel isolation question
... How are syscalls dealt in other RTOS using MPU? For the case of the MPU, there is no general answer to that. I don't think that there is any standard model for the use of the MPU in a Unix-like system. NuttX uses the MPU to create a Kernel space with the OS and critical board logic in it and a separate user space for applications. That is inspired by the standard Unix kernel + applications model. But every use of the MPU that I am familiar with in deeply embedded bare-metal or tiny RTOS systems are totally custom solutions. For the MMU (which you might think of as an MPU with address mapping), the Unix model is the only one I am familiar with. As in Linux, a kernel blob and applications loaded into RAM from a file system. Greg
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 11:59 PM Gregory Nutt wrote: > > 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. > Since all arch need save the function return address into stack eventually, if userspace pass a pointer inside the stack and request kernel read the file provided by userspace to this pointer, then kernel may get the wrong return address and run the malicious code with the highest privilege. The keypoint isn't whether we use two(user/kernel) stack or single stack, but the kernel may corrupt the return address saved in the stack and then jump to the attacked code before low the privilege. > > > >>> 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. > For Linux, most security bug is found inside drivers not core part. > 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). > As my explanation before, even the same thread also has the bug I described. Acttually, what I describe is a very basic exploition. > Greg > >
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 5:08 PM Nathan Hartman wrote: > ... > If you need the sort of "security" that makes it possible to run > totally untrusted code, then maybe you need a full blown operating > system, which also comes with a full blown computer and not an > embedded microcontroller. > Despite it could be an "overkill" for most use cases, for other use cases it may be needed and not impacting too much in performance. It could be disabled if not needed. At least, these limitations/issues should be well documented, since it is not unusual that people, if not explicitly stated, assume that the same restriction as in Linux or other common OS apply to NuttX. How are syscalls dealt in other RTOS using MPU? I have little experience in that regard. Cheers, Miguel
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt wrote: 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). The whole point of using a RTOS is to get a LIGHTWEIGHT operating system. This is for embedded microcontrollers costing from cents up to a few dollars in products that run embedded software logic. If you need the sort of "security" that makes it possible to run totally untrusted code, then maybe you need a full blown operating system, which also comes with a full blown computer and not an embedded microcontroller. Hi, Nathan, I think you are hitting on the crux a very important discussion that needs to be had about IoT directions. Historically, IoT OS's have been primitive little things from Contiki, RIOT, MyNewt, Zephyr, etc. But IoT vendors have become very aware of security issues. Imagine the consequences if someone could hack into your smart home, your IoT based utilities, security system, or your car. Automotive is really driving security issues in small MCUs. Breaking into Xiaomi smart home IoT systems has quite a few followers in the hacker world. So IoT needs high quality, more-or-less undefeatable security. Distributed systems also need remote updates and customizations as you would be from the use of installable ELF files. And, yes, you are right. Embedded systems need to be small, low cost, with minimal resources. I don't really know how to resolve all of this. The discussion, I think, involves only PROTECTED and KERNEL builds. So I would hope that any additional security burden would apply only to those builds without impacting the FLAT builds. I think in the case of PROTECTED and KERNEL builds, increased memory usage will be a natural consequence of adding security features. If such a base kernel could be produced in a few 100's of Kb, then I think it would still be a viable solution for that space. Still more questions than answers. Greg
Re: userspace/kernel isolation question
Hello, I dont agree. A fundamental feature to avoid widespread developement of the so-called Internet of Shit is basic embedded security. Some thoughts: An embedded system can have a minimal security. Of course security has several levels from non-existent to ideal. Not having a full PKI protected secure boot does not mean some protections could not be used. The question here is not adressable generally in ALL embedded systems, but the use of the ARM MPU could help a lot. As anyone probably already knows, the ARM MPU is a MMU with a one-one virtual/physical mapping. It can be used to enforce access rights on selected memory zones. The MPU could be updated at each task switch to ensure that only the mem zones for the current task are usable. The MPU could prevent the user app from reading the kernel flash and RAM when running in user space. Starting a system call then enables the MPU settings for supervisor mode. The system calls could check the validity of passed pointers against the currently valid memory protection settings to avoid clobbering and reading kernel and/or other task memory zones. This single feature does not even need an MPU, just knowledge of application address boundaries. True, it is complex and would need linker support or loadable apps. True, it could be bypassed, but the requirements to do that would be a bit more complex than nothing. Any security feature available should be used. It is a common fallacy to state that bypassable security is not useful. It is still better than no security at all. It can also be useful to prevent... well, plain memory corruption bugs. Sebastien Le 25/02/2020 à 17:08, Nathan Hartman a écrit : On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt wrote: 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). The whole point of using a RTOS is to get a LIGHTWEIGHT operating system. This is for embedded microcontrollers costing from cents up to a few dollars in products that run embedded software logic. If you need the sort of "security" that makes it possible to run totally untrusted code, then maybe you need a full blown operating system, which also comes with a full blown computer and not an embedded microcontroller. Cheers, Nathan
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt wrote: > > 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). The whole point of using a RTOS is to get a LIGHTWEIGHT operating system. This is for embedded microcontrollers costing from cents up to a few dollars in products that run embedded software logic. If you need the sort of "security" that makes it possible to run totally untrusted code, then maybe you need a full blown operating system, which also comes with a full blown computer and not an embedded microcontroller. Cheers, Nathan
Re: userspace/kernel isolation question
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
Re: How (or where) does the enque function sends the data to hardware....
Or... Do I have to *write the data to corresponding hardware registers in the enque itself *and wait for the interrupt routine to receive the data and release the semaphore? Basically enque of Lpc17xxx (which I am using as reference) seems generic and not updating any hardware registers... With best regards, Phani. On Tue 25 Feb, 2020, 8:35 PM Phani Kumar, wrote: > Hi Greg and all, > I am developing the USB Host driver for RX65N, and using lpc17xxx port as > my basic reference. Currently I can detect the device and initiate the > standard "usbhost_enumerate()" function. This calls tballoc twice and > prepares the buffer for (i) first setup packet request and (ii) for data to > be received. This results in series calls to > xxx_usbhost_ctrlin() //Think this is getting ready for reading the > returend data from device > -> xxx_usbhost_ctroltd () //This creates the Transfer Descriptror for the > data transer > -> xxx_usbhost_alloc_xfrinfo () //Prepares the data to be transmitted > (setup packet to get teh device descriptor) > -> and finally xxx_enquetd () //this prepares the pointers ready to be > transmitted > and then waits for completion on semaphore > Some how I am not able to figure out, who/how transfer the data to actual > hardware registers here? If the host keeps keeps pumping the data (with > enque), where does the deque i.e. taking this out and sending out to device > happens? > Think I am missing very basic thing. Let me know if you have any pointers/ > suggestion for me. > With best regards, > Phani. > >>
How (or where) does the enque function sends the data to hardware....
Hi Greg and all, I am developing the USB Host driver for RX65N, and using lpc17xxx port as my basic reference. Currently I can detect the device and initiate the standard "usbhost_enumerate()" function. This calls tballoc twice and prepares the buffer for (i) first setup packet request and (ii) for data to be received. This results in series calls to xxx_usbhost_ctrlin() //Think this is getting ready for reading the returend data from device -> xxx_usbhost_ctroltd () //This creates the Transfer Descriptror for the data transer -> xxx_usbhost_alloc_xfrinfo () //Prepares the data to be transmitted (setup packet to get teh device descriptor) -> and finally xxx_enquetd () //this prepares the pointers ready to be transmitted and then waits for completion on semaphore Some how I am not able to figure out, who/how transfer the data to actual hardware registers here? If the host keeps keeps pumping the data (with enque), where does the deque i.e. taking this out and sending out to device happens? Think I am missing very basic thing. Let me know if you have any pointers/ suggestion for me. With best regards, Phani. >
Re: userspace/kernel isolation question
On Tue, Feb 25, 2020 at 10:08 PM Gregory Nutt wrote: > > > > 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. > > 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. > Greg >
Re: userspace/kernel isolation question
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. 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). Greg
Re: Usrsocktest app example fails
I try the test on simulator, and all cases pass without exception, maybe you can try the simulator in your environment to ensure your modification don't affect the system. On Mon, Feb 24, 2020 at 7:31 PM Oleg Evseev wrote: > Hi Xiang, > > I've checked https://github.com/apache/incubator-nuttx/pull/354 PR. It > fixed issues it supposed to fix, thanks. > > But I've still have semaphore assertion running test case > WakeBlockingConnectMultiThread > in do_wake_test() on third call in loop of sem_post(&tid_releasesem) when > tidx is 2. > (examples/usrsocktest/usrsocktest_wake_with_signal.c:515) > [image: изображение.png] > > As I understand, you do not have such issue, so it's looks like reason is > totally somewhere in my configuration. > Especially due to fact that, as I wrote, I'm playing with it on Windows > inside px4 project on my custom board with stm32f405, using latest original > nuttx and apps. > > I had tried to increase twice CONFIG_EXAMPLES_USRSOCKTEST_STACKSIZE, it > didn't help, assertion in the same place. > > сб, 22 февр. 2020 г. в 18:11, Xiang Xiao : > >> The semaphore assertion look like the memory corrruption(maybe the >> stack too small) which platform you are running. >> >> On Sat, Feb 22, 2020 at 6:52 PM Oleg Evseev wrote: >> > >> > Hi Xiang, >> > >> > I can check it only on Monday, thanks! >> > >> > But, by the way, in commits you mentioned several errors in usrsocktest >> > that looks different than on my first screenshot (especially debug >> > assertion failed somewhere inside semaphore). Maybe there will still be >> > problems due to my wrong settings. Will see after checking this PR. >> > In any case, thanks for your time and support! >> > >> > сб, 22 февр. 2020 г. в 13:38, Xiang Xiao : >> > >> > > Oleg, try this PR: >> > > https://github.com/apache/incubator-nuttx/pull/354 >> > > with Masayuki and my patch, all test in usrsocktest should pass now. >> > > Actually, all fail is very minor: >> > > 1.Set the different errno >> > > 2.Foget to check NULL pointer >> > > 3.Don't zero the sockaddr padding bytes >> > > ,usrsock work well very even without these patch. >> >
Re: Build is broken
David, patch is here: https://github.com/apache/incubator-nuttx-apps/pull/95 Thanks Xiang On Tue, Feb 25, 2020 at 8:26 PM David Sidrane wrote: > > Hi Takashi, > > Thanks for looking at this. > > Yes. Linux > > To test it should I revert the revert and then apply the commit or is there > a PR I should test? > > David > > -Original Message- > From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID] > Sent: Monday, February 24, 2020 10:46 PM > To: dev@nuttx.apache.org > Subject: Re: Build is broken > > may i assume you are using linux? > > here's a fix i tested on ubuntu. > https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d > > On Sat, Feb 22, 2020 at 1:21 AM David Sidrane > wrote: > > > > This is what I did: > > > > For apps and nuttx git fetch nuttx > > For apps and nuttx git checkout master > > For apps and nuttx git reset -hard nuttx/master > > > > make distclean > > ./tools/configure.sh imxrt1060-evk:nsh > > make oldconfig > > make > > > > The results are as shown. > > > > Why are we changed the build system without testing on braches? > > > > David > > > > -Original Message- > > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > > Sent: Friday, February 21, 2020 7:17 AM > > To: dev@nuttx.apache.org > > Subject: Re: Build is broken > > > > On Fri, Feb 21, 2020 at 10:13 AM David Sidrane > > wrote: > > > > > Build is broken > > > > > > Build is broken > > > > > > And the output looks very ODD - any ideas on what happened? > > > > > > > > Have you tried make distclean, reconfigure, retry build? > > > > If so, could you run a bisect since the last good known build and identify > > the offending commit? > > > > Thanks > > Nathan
RE: Build is broken
Hi Takashi, Thanks for looking at this. Yes. Linux To test it should I revert the revert and then apply the commit or is there a PR I should test? David -Original Message- From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID] Sent: Monday, February 24, 2020 10:46 PM To: dev@nuttx.apache.org Subject: Re: Build is broken may i assume you are using linux? here's a fix i tested on ubuntu. https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d On Sat, Feb 22, 2020 at 1:21 AM David Sidrane wrote: > > This is what I did: > > For apps and nuttx git fetch nuttx > For apps and nuttx git checkout master > For apps and nuttx git reset -hard nuttx/master > > make distclean > ./tools/configure.sh imxrt1060-evk:nsh > make oldconfig > make > > The results are as shown. > > Why are we changed the build system without testing on braches? > > David > > -Original Message- > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > Sent: Friday, February 21, 2020 7:17 AM > To: dev@nuttx.apache.org > Subject: Re: Build is broken > > On Fri, Feb 21, 2020 at 10:13 AM David Sidrane > wrote: > > > Build is broken > > > > Build is broken > > > > And the output looks very ODD - any ideas on what happened? > > > > Have you tried make distclean, reconfigure, retry build? > > If so, could you run a bisect since the last good known build and identify > the offending commit? > > Thanks > Nathan
