On Mon, Mar 2, 2020 at 9:05 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Mon, Mar 2, 2020 at 9:33 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Sat, Feb 29, 2020 at 2:58 PM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: >> > >> > I have gone through the details of the project adding memory protection >> > using MMU and have a few questions and observations regarding the same- >> > >> > 1. Is this a project for which someone from the community would be willing >> > to mentor for GSoC? >> >> Yes, Peter Dufault has expressed interest. There are also several >> generally interested parties that may like to stay in the loop. >> >> > 2. As far I could understand by looking into the rtems tree ARM uses >> > static initialization wherein it first invalidates the cache and TLB >> > blocks and then performs initialization by setting up a 1 to 1 mapping of >> > the parts of address space. According to me, static initialization of the >> > mmu is a generic enough method that can be utilized in most of the >> > architectures. >> >> Yes, it should be. That is how most architectures will do it, if they >> need to. Some might disable the MMU/MPU and not bother, then there is >> some work to do to figure out how to enable the static/init-time >> memory map. >> >> > 3. For the thread stack protection, I believe either of the stack guard >> > protection approach or by verification of stack canaries whereby the OS on >> > each context switch would check whether the numbers associated with the >> > canaries are still intact or not are worth considering. Although I still >> > only have a high-level idea of both of these approaches and will be >> > looking into their implementation details, I would request your kind >> > feedback on it. >> > >> >> Thread stack protection is different from stack overflow protection. >> We do have some stack overflow checking that can be enabled. The >> thread stack protection means you would have separate MMU/MPU region >> for each thread's stack, so on context switch you would enable the >> heir thread's stack region and disable the executing thread's region. >> This way, different threads can't access each other's stacks directly. > > > FWIW the thread stack allocator/deallocator plugin support was originally > added for a user who allocated fixed size stacks to all threads and used > the MMU to invalidate the addresses immediately before and after each > stack area. > > Another thing to consider is the semantics of protecting a thread. Since > RTEMS is POSIX single process, multi-threaded, there is an assumption > that all data, bss, heap, and stack memory is accessible by all threads. > This means you can protect for out of area writes/reads but can't generally > protect from one thread accessing another thread's memory. This may
Right: thread stack protection must be application-configurable. > sound like it doesn't happen often but anytime data is returned from a > blocking call, the contents are copied from one thread's address space > to another. Message queue receives are one example. I suspect all > blocking reads do this (sockets, files, etc) > It should not happen inside rtems unless the user sends thread-stack pointers via API calls, so the documentation must make it clear: user beware! It may eventually be worth considering (performance-degrading) extensions to the API that copy buffers between thread contexts. But yes, we are operating outside of POSIX. > --joel >> >> >> Gedare >> >> > Regards, >> > Utkarsh Rai. >> > >> > On Fri, Feb 21, 2020 at 10:28 PM Utkarsh Rai <utkarsh.ra...@gmail.com> >> > wrote: >> >> >> >> Thanks, I will check it out. >> >> >> >> On Fri, Feb 21, 2020 at 12:56 AM Gedare Bloom <ged...@rtems.org> wrote: >> >>> >> >>> On Tue, Feb 18, 2020 at 12:45 PM Utkarsh Rai <utkarsh.ra...@gmail.com> >> >>> wrote: >> >>> > >> >>> > Based on your feedback, adding memory protection or enhancing Wi-fi >> >>> > Support in libbsd are two projects that I would like to work upon. >> >>> > >> >>> > For MMU support I think a lot unmerged PowerPC code is already >> >>> > present, but since I would be using BBB I would only be able to use >> >>> > that as a reference. Is it feasible to start it from scratch? >> >>> > >> >>> The state-of-the-art has advanced in the rtems.git tree since these >> >>> projects happened, and it is not all documented. The ARM in particular >> >>> generally uses a static initialization or boot-time initialization of >> >>> the MMU. You should study how the ARM approach works in the RTEMS >> >>> main repo, and consider whether that approach can be adopted by other >> >>> architectures/BSPs, how to improve that approach, and how to build >> >>> higher-level services on top of the low-level BSP support that exists. >> >>> >> >>> One of the main interesting applications is to provide thread stack >> >>> protection. >> >>> >> >>> > For Wi-Fi support, I would require an RTL8188 USB dongle along with >> >>> > JTAG for debugging purposes. I am not quite sure about how to handle >> >>> > the 'hot-plugging' case in this project it would be very helpful if >> >>> > someone could point me in the right direction. >> >>> > >> >>> I can't speak to the WiFi support, maybe others know. But to get >> >>> started you would need to at least demonstrate that you have the >> >>> necessary hardware to succeed and that you can at a minimum boot/run >> >>> BBB with libbsd, and probably we should like you to show that you can >> >>> generate patches for libbsd. >> >>> >> >>> Gedare >> >>> >> >>> > >> >>> > On Tue, Feb 18, 2020 at 1:21 AM Gedare Bloom <ged...@rtems.org> wrote: >> >>> >> >> >>> >> >> >>> >> On Mon, Feb 17, 2020 at 9:42 AM Utkarsh Rai <utkarsh.ra...@gmail.com> >> >>> >> wrote: >> >>> >>> >> >>> >>> Hello everyone, >> >>> >> >> >>> >> Hello Utkarsh Rai, >> >>> >> >> >>> >>> >> >>> >>> I would like to contribute to the Beagleboard BSP project, in >> >>> >>> particular towards the improvement of the peripheral support. I have >> >>> >>> a few questions pertaining to the same:- >> >>> >>> >> >>> >>> 1. Is adding support for Ethernet and USB a reasonable goal for the >> >>> >>> duration of the GSOC? >> >>> >>> >> >>> >>> 2. FreeBSD has support for Ethernet and USB can we port that to >> >>> >>> libbsd? >> >>> >>> >> >>> >>> 3. What are the deliverables for this project, for instance, would I >> >>> >>> be required to add shell support for these peripherals or maybe an >> >>> >>> example app? >> >>> >>> >> >>> >>> I have also attached a screenshot of the changed 'hello world' >> >>> >>> program along with this email >> >>> >> >> >>> >> Thanks. It is nice to see that you already ran it successfully on the >> >>> >> BBB. >> >>> >> >> >>> >> As of now, the BBB has quite mature support including Ethernet and >> >>> >> USB. There is another student actively working on a proposal to >> >>> >> expand our BBB support a bit further. I'm not certain if there is >> >>> >> sufficient work/interest/mentoring available to support multiple BBB >> >>> >> projects. You might consider what specific projects would interest >> >>> >> you though. You should take a look at past years' GSoC projects >> >>> >> documented on our wiki, they are linked from our main 'GSoC' page. >> >>> >> >> >>> >> There are also lots of interesting projects that can be done in a >> >>> >> BSP-agnostic way, but still could be valuable to test with the BBB. >> >>> >> The most important aspect about doing development with a BBB is that >> >>> >> you can use the JTAG, which requires some soldering and additional >> >>> >> effort to work with a standalone JTAG debugger. If you don't have >> >>> >> that, and want to work with the BBB, it is highly recommended. >> >>> >> >> >>> >> >> >>> >>> >> >>> >>> _______________________________________________ >> >>> >>> devel mailing list >> >>> >>> devel@rtems.org >> >>> >>> http://lists.rtems.org/mailman/listinfo/devel >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
