> > *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.* >
I do not think the strategy I discussed would be pointless. If your worker application was required to speak with a supervisor service, and the supervisor was the only part that had direct access to the PRU. There would be no problem, unless your attacker gained root, at which point you're already too far gone. Also, /dev/mem/ + mmap() are identical to the PRU in relation to having direct access to any memory address. Which is why many people have concerns when it is used. On Mon, Jun 27, 2016 at 8:59 AM, Przemek Klosowski < [email protected]> wrote: > On Mon, Jun 27, 2016 at 3:51 AM, TJF <[email protected]> wrote: > > 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. > > This is a valid design pattern and you did very impressive things with > it, but it's not compatible with the basic design of Linux hardware > integration: I don't know of a single mainline kernel driver designed > this way. The whole point of a kernel driver is that it abstracts the > hardware and presents the unified abstraction to the rest > (open/read/write/ioctl/skbuf/etc). Of course this costs performance, > and so the development identifies those bottlenecks and tries to come > up with more abstractions like no-copy networking, etc. > The challenge for those abstractions is to provide speed while still > maintaining security, e.g. by disallowing full control of the entire > physical address space. There have to be address space checks on those > kernel-userspace transitions, and they will use up some cycles; you > can optimize them but can't just not do them. > > It seems to me that you just don't want the Linux machinery to > intervene: your design does feel like a bare metal, tight control > loop, using Linux mostly for setup, program loading and > administration. > > Also, I would be personally obliged to you if you could refrain from > commenting on other people's motivations and abilities, and just keep > focused on the technical points everyone is making. The discussion is > much more productive this way. > > -- > 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/CAC%3D1GgGAQBn%2BAgt76ivjMW3h3Yon7hXbEROcU%2BwubWS4YG6%3DJg%40mail.gmail.com > . > For more options, visit 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/CALHSORpaiVnPa3ZX7_-takyOgocki91-cQK4nrR0CPjcLm4HaA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
