I think there is a LOT of misconception as to what uio_pruss *is*. Or what *any* UIO driver is - period.
#1 a UIO driver is kernel side first. There is no userspace side driver with out a UIO kernel driver stub. So, if you create your own kernel side "stub"( as done with uio_pruss ) it can be as complex, or as simple as needed. #2 I always treat security risks as if an intruder has already gained access to at least a regular user account. When you think of the problem from this angle, you start thinking how it's best to write programs that are hard to compromise. So, if you're concerned about uio_pruss being a security risk. Then write your userspace program in two halves. root / superviser service + regular user / worker program. Worker program can NOT do anything the supervisor service will not let it do. Passed that, if an intruder gains access to root. You're already screwed, so you can relax ;) #3 Someone, or some people do not understand how fast userspace can be, when you write proper applications with performance in mind. *You* can tell me until you're blue in the face that implementations including, and using /dev/mem/ + mmap() are a bad idea, because of the "reindeer effect", or whatever. The thing is, I already know what the good, and bad implications of using /dev/mem/ + mmap() are. So why would I need anyone elses advice on it ? Hint: I don't. If you think it's a bad idea, then fine. Do not use it. Let the big boys write the performant applications. But do not try and pee on my leg, and tell me it's raining. Because I do have a brain of my own. Passed that, sticking to API calls that do not copy data to, and from the kernel. Or otherwise stall an application because of context switching, or any number of reasons - is best practice. But you have to know this to begin with, and then bother in trying to make things work the way you need, or want them to work. Not just toss something together, and complaining when it does not live up to your performance standards. e.g. You should probably consider learning how to write code properly . . . Or let someone else do it. So, what does /dev/mem/ + mmap() have to do with the PRU's ? Nothing really. Except if you expect to keep up with programmable high speed peripherals. You're going to need every bit of speed your application can muster. Then, if you can not trust me when I say that /dev/mem/ + mmap() is easily 100's or 1000's times faster than standard libc / POSIX calls / sysfs. Then go experiment on your own to prove to yourself. Me, again, I do not need any advice. I've already tested on my own. On Sun, Jun 26, 2016 at 2:53 AM, TJF <jeli.freih...@gmail.com> wrote: > @John3909: > > Am Samstag, 25. Juni 2016 21:53:10 UTC+2 schrieb john3909: >> >> Why don’t you use the “bone” kernel which pruss_uio as default. >> > > That's what I do. > > >> The “ti” kernel has RemoteProc/RPMSG as default. I don’t understand you >> problem here. >> > > There'll be no more problem when we follow my proposal and remove the > remoteproc framework from the mainstream. But in the current situation the > problem is to find an answer when a user asks "How to test a ti-rt kernel > with libpruio?". > > >> Look at the BeagleLogic development blog, where he explains the >> throughput problem with pruss_uio. When he changed to RemoteProc/RPMSG, the >> throughput increased dramatically. >> > > Why should I spent time on that investigation? Better convince me by > telling me: how much do you think your thingy can increase libpruio > throughput? > > >> I continue to say that you are using RemoteProc/RPMSG incorrectly. >> > > Obviously you have no idea how libpruio works and you have no experience > on the usecase it's made for. Do you really think you can give a > professional opinion on correct or incorrect? I'm sure I use it correct, > because I don't use it at all, since it doesn't fulfill the requirements. > > >> You shouldn’t have a tight control loop between the PRU and ARM because >> this makes no sense. Linux is non deterministic so why would you want to >> compromise the PRU by making it dependent on the communications with Linux. >> Either use one PRU for the control loop and another for communicating with >> Linux, or use DMA to pass data between PRU and ARM. >> > > 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.) > > >> These are generally toys. The vast majority of drivers are Kernel based >> drivers. >> > > I don't know all the other drivers you stated here. But in case of > one-wire your "generally toys" (all four) do the heavy work in real world > projects. Because your "vast majority" (I count one) isn't able to perform > a simple broadcast trigger for multiple Dallas sensors, and misses lots of > other features like setting limits, ... In my experience, and in case of > one-wire usecase, the kernel driver is the toy. And there're much and good > reasons why the userspace drivers are under continuous development (and the > kernel driver isn't). > > Try a little bit thinking outside your box. > > Once you compromise physical security, you have no security, period, so >> this is a silly point to make. There a many Linux device drivers that rely >> on firmware and these are all done is a secure way. The purpose of a kernel >> driver is to validate the user parameters and prevent operations outside >> well defined limits. Userspace drivers have no such validation and can do >> whatever they please, hence no security. >> > > My libpruio driver has lots of validations. Ie. you can find many posts at > this forum regarding a validation bug, where the maximum sampling rate for > ADC sampling was calculated too much on the save side. Do you really think > that only kernel code can validate? > > But please read my statement again. I'm not talking about physical > security, nor about arbitrary periperals. I'm talking about the PRUSS and > their firmware, which can access all CPU memory without any kernel > protection. I'm talking about software security. > > >> Hence why you want to Kernel based driver to validate the firmware. >> Again, userspace driver can place whatever code it wants on the PRU. >> > > Right, whatever code it wants. Ie. a virus. And it's really hard to find a > virus running on the PRUSS. Currently, I see no way how a kernel driver > should validate if the firmware is free of virus. And when firmware is > loaded from files and started by command line, it's much more easy to run a > virus on the PRUSS, in contrast to loading and running it by prussdrv. With > remoteproc, it even doesn't need any command line action: just copy the > virus to /lib/firmware and name it am335x-pru$[0|1]-fw, and it will run at > next boot time. This is a massive safety risc in the current remoteproc > concept. It shouldn't be that easy to install and run malware. > > TI have several processors that have PRU, DSP, CortexM4 in addition to one >> or more ARM processors. Just look at the BeagleBoard-x15 for example. >> > > How is this related to my statement you qouted? > > This framework works for me so I certainly don’t want it removed. >> > > Fine, go ahead. (BTW: which projects did you realise yet?) > > Once you read my statements again, you'll find out that I only want to > remove a dangerous software from the mainstream, but not completely. So you > can still use your be-loved thingy. Just load it as an option. > > >> I think it would be more productive to make suggestions on how to improve >> the RemoteProc/RPMSG. BTW, I’m sure you don’t have any problem with >> RemoteProc, because it is just loading and starting/stopping the firmware >> on the PRU. PRUSS_UIO has a similar firmware loader. So perhaps we should >> concentrate on Virtio, vring or RPMSG. >> > > Once again, I've problems with remoteproc. And I've problems with the > framework and its design. It doesn't make sense to talk about details. In > order to make this framework usable, it needs talk about general issues, > like > > Do we really need PRU access from kernel space? > If so, how to handle the additional riscs? > ... > > And this needs other than traditional thinking, since riscs regarding the > PRUSS are different from riscs handled by any kernel driver before. > > But this discussion is pointless, since Suman said that he don't want to > start from scratch. (He may change his mind when he reconsiders the riscs > of the current design.) > > >> Once again, why not install the “bone” kernel which has pruss_uio as >> default. Why do you insist on installing the “ti” kernel which has >> RemoteProc/RPMSG as default and then insist on removing RemoteProc/RPMSG. >> This makes no sense to me. >> > > See my answer above. TI kernels do not only differ from remoteproc. Some > of my users want to test the real-time features, which aren't in the bone > channel. I try to help them. I try to find a way that prefers corporate > development to mutual exclusion by downgrading. > > >> The reason it was added to mainstream was to encourage support by other >> vendors which has already started. >> > > Obviously too early. > > >> Since pruss_uio is only supported on one platform, it shouldn’t be >> included in mainstream. >> > > An unsave, experimental framework also shouldn't be included in > mainstream. I'd try to make both optional and choise in device tree when > enabling the PRUSS. > > BR > > -- > 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 beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/d9d9f9ee-8ba7-4ff0-a874-965f8d1a61c2%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/d9d9f9ee-8ba7-4ff0-a874-965f8d1a61c2%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqAE7kF3hLPcL9ZUkwp1Cb30MBarCj7oW3FLd9FNv-VGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
