> On Jun 27, 2016, at 1:49 AM, John Syne <[email protected]> wrote: > > >> On Jun 27, 2016, at 12:51 AM, TJF <[email protected] >> <mailto:[email protected]>> wrote: >> >> @John3909: >> >> Am Sonntag, 26. Juni 2016 20:13:12 UTC+2 schrieb john3909: >> It makes no sense to discuss that in detail here, since you obviously have >> no idea on rapid prototyping controllers. (I can give you a private lesson >> if you like.) >> On the contrary, perhaps you should explain the use case so everyone here >> can understand what it is you cannot do with RemoteProc/RPMSG. Give some >> examples of how you do this with libpruio. I just don’t understand the need >> for communications with Linux in a tight control loop, but I’m hoping you >> can enlighten us on the issue ... >> >> I think Suman did already know what libpruio (and many other high >> performance PRU projects) need. But here's a private lesson for you: There >> is no "need for communications with Linux in a tight control loop". We need >> direct memory access between PRU and ARM CPU. No Linux inbetween. We need to >> bypass all that vring and RPMsg magic. We gain for speed and small memory >> footprints. We want to save resources for future extensions and we don't >> want to spend resources for features that we neither need nor want. > While I haven’t tried this, I don’t believe there is anything in the > RemoteProc/RPMSG framework that prevents you from doing this now. You can > still use RemoteProc to load/start/stop your PRU firmware and you don’t have > to use virtio or rpmsg, but rather create a new KM to do just this. Suman > does this make sense? So, thinking a little more about this, this new KM would support mmap() so that your userspace app/lib could access this memory directly. Linux is out of the way and yet everything is still secure ;-)
Regards, John >> >> ... and hopefully move this discussion forward. >> >> To get this discussion forward, we have to move backwards. Neither Suman nor >> myself want this. So the best way to solve the conflict is, that we get both >> of our concepts optional. The user should decide if he wants to drive a >> Jaguar or a Bentley. >> >> Since the Bentley has an open trunk where any agressor can easy hide a big >> bomp, it is a MUST-HAVE to get it out of the mainstream. Remeber, PRUSS can >> access ALL memory. A PRU virus can even override kernel space memory or >> manipulate kernel drivers. All the safety strategies you explained to >> William are pointless when a PRU virus overrides your instructions. With >> network access, a small loader on the PRU could exchange the complete >> system, auto-started by remoteproc at boot time. And all that vring and >> RPMsg magic make it even more easy to develop such a malware. Currently, >> remoteproc is some kind of VCE (virus construction environment), inbuild in >> the kernel source. > So how do you propose to modify the PRU firmware without root access? On the > other hand, your libpruio app runs in userspace, so it is easy to swap out > that app and bypass all security. >> >> I wonder how you can speak about safety and support such a concept at the >> same time. If you're not just declaiming phrases you learned at highschool, >> if you have a brain of your own and you're using it, if you really were >> interested in security, you would second my proposal to make remoteproc >> optional, and remove it from mainstream. > Your childish antics say more about you and this isn’t helpful in this > discussion. Keep the discussion professional and reframe from getting > personal. You really are not listening, RemoteProc/RPMSG are here to say > because of all the other processors TI support and several other vendors have > decided to support this framework also. Nothing you say is going to change > that. All you can do is request that it is improved to suite your needs, or > you will have to build your own custom kernel without RemoteProc/RPMSG to > support libpruio. RemoteProc/RPMSG will be the standard interprocessor > communications framework in Linux. Take this chance to influence the > development. Everything else is futile. >> >> Think of this discussion as a cooperative one were everyone should >> ultimately benefit. >> >> Fine that we are at one with this, and you are also ready for corporate >> development, now. > This is so silly and you should be better than this. > > Regards, > John >> >> BR >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <http://beagleboard.org/discuss> >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beagleboard/ebf4bf3f-b545-4efe-9af8-0cb07833217a%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/ebf4bf3f-b545-4efe-9af8-0cb07833217a%40googlegroups.com?utm_medium=email&utm_source=footer>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/B0CDFC6E-FD8B-4129-925B-552769D27FF0%40gmail.com. For more options, visit https://groups.google.com/d/optout.
