On Mon, Mar 2, 2020 at 9:37 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Mon, Mar 2, 2020 at 10:12 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> 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! > > > Yep. Pushing this to the limit could break code in weird, hard > to understand ways. The fault handler may have to give a hint. :) > >> >> It may eventually be worth considering (performance-degrading) >> extensions to the API that copy buffers between thread contexts. > > > This might be challenging to support everywhere. Say you have mmu_memcpy() > or whatever. It has to be used inside code RTEMS owns as well as code that > RTEMS is leveraging from third party sources. Hopefully you would at least > know the source thread (running) and destination thread easily. >
This brings up the interesting design point, which may have been mentioned elsewhere, that is to group/pool threads together in the same protection domain. This way the application designer can control the sharing between threads that should share, while restricting others. > >> >> But >> yes, we are operating outside of POSIX. > > > And likely the C Standard as of C11 with threads. > >> >> >> > --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
