> > *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.* >
By the way. You could lock down the PRUs the same way /dev/mem/ is locked down. /dev/mem/ requires root privileges. On Mon, Jun 27, 2016 at 11:14 AM, William Hermans <[email protected]> wrote: > *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/CALHSORrgvE6hHNTbp0mXhqML3%3DA2vJNRCgqjDMpg5Pcr8%3DoqbQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
