So reading the UIO docs; https://www.kernel.org/doc/htmldocs/uio-howto/about.html <https://www.kernel.org/doc/htmldocs/uio-howto/about.html>
"For some hardware that has more than one interrupt source internally, but not separate IRQ mask and status registers, there might be situations where userspace cannot determine what the interrupt source was if the kernel handler disables them by writing to the chip's IRQ register. In such a case, the kernel has to disable the IRQ completely to leave the chip's register untouched. Now the userspace part can determine the cause of the interrupt, but it cannot re-enable interrupts. Another cornercase is chips where re-enabling interrupts is a read-modify-write operation to a combined IRQ status/acknowledge register. This would be racy if a new interrupt occurred simultaneously.” To address this issue, you are required to write a UIO Kernel Module: https://www.kernel.org/doc/htmldocs/uio-howto/custom_kernel_module.html <https://www.kernel.org/doc/htmldocs/uio-howto/custom_kernel_module.html> Now with reference to handling interrupts: https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html <https://www.kernel.org/doc/htmldocs/uio-howto/adding_irq_handler.html> "If, on the other hand, your hardware needs some action to be performed after each interrupt, then you must do it in your kernel module. Note that you cannot rely on the userspace part of your driver. Your userspace program can terminate at any time, possibly leaving your hardware in a state where proper interrupt handling is still required." Regarding /dev/mem, how does a userspace app access /dev/mem? In a secure system, you shouldn’t be running your app as root and there should be no member of the kmem group. This feature is more for hacking and debugging purposes, not serious application development. Regards, John > On Jun 26, 2016, at 12:11 PM, William Hermans <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 > <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/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 > <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/CALHSORqAE7kF3hLPcL9ZUkwp1Cb30MBarCj7oW3FLd9FNv-VGQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORqAE7kF3hLPcL9ZUkwp1Cb30MBarCj7oW3FLd9FNv-VGQ%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/BC63C42A-9D23-40C1-947A-1E94B22928A4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
