> On Jun 27, 2016, at 11:16 AM, William Hermans <[email protected]> wrote: > > 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. Which is essentially the problem and why I do not like /dev/mem for application development. For testing out a concept or debugging kernel code, then it is a powerful tool. > > On Mon, Jun 27, 2016 at 11:14 AM, William Hermans <[email protected] > <mailto:[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] <mailto:[email protected]>> wrote: > On Mon, Jun 27, 2016 at 3:51 AM, TJF <[email protected] > <mailto:[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 > <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:beagleboard%[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 > > <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 > <https://groups.google.com/d/optout>. > > > > -- > 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/CALHSORrgvE6hHNTbp0mXhqML3%3DA2vJNRCgqjDMpg5Pcr8%3DoqbQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORrgvE6hHNTbp0mXhqML3%3DA2vJNRCgqjDMpg5Pcr8%3DoqbQ%40mail.gmail.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/1B3B690F-D37B-4E40-98B9-3528A4B3B895%40gmail.com. For more options, visit https://groups.google.com/d/optout.
