> On Jun 30, 2016, at 2:11 AM, TJF <[email protected]> wrote: > > Good morning John! > > Am Mittwoch, 29. Juni 2016 17:07:05 UTC+2 schrieb john3909: > What a silly argument. It is well known that when you don’t have physical > security, you don’t have any security. Once you can replace the storage > media, you can make the hardware do whatever you want. This is true of your > laptop and your servers. Clearly by your argument, you haven’t even begun to > understand security. > > You're correct, I don't know much about the Linux terminologie and > definitions. From the Linux point of view, this was evidently a silly > argument. Do not fred. You're still leading by a two-digit score in this > discipline. > > Does that change much? No, there're still other ways to get firmware on the > PRUSS. As a matter of fact there are solutions to use the PRUSS from user > space. No example, because I don't want to continue in publishing "how to > make a virus" tutorials here. If you don't believe that, just check out the > libpruio examples. Most of them work with user privilegues, root permission > is necessary for pinmuxing only. The only reason you can do this from userspace is because of uio_pruss. It is the UIO driver that exposes the PRU memory to user space that creates this security hole. With RPMSG/RemoteProc, there is no uio_pruss and so you cannot install custom code to the PRU without root permission. > > In addition, you should reframe from impugning a person's motivations or > intentions. > > It's confusing when you talk to yourself. > > If you didn’t know, for stability reasons, Linux do not remove fameworks > unless they have been replaced by something better and in most cases the new > framework is backward compatible with the new framework. > > Obviously there're exceptions. The PRU support is neither better nor backward > compatible to previous solutions. Oh sorry, not entirely correct: indeed it > has better support for PRU virus activities, targeting the kernel space > directly. You still haven’t explained how to load custom code onto PRU using RemoteProc without root permission. Looking in /lib/firmware, user and group permissions are always root. There are only two ways to load PRU firmware and that is at boot time because of DT PRUSS driver definition or via sysfs and this requires root permission. > > No one knows how many developers are using RemoteProc/RPMSG ... > > This is an important point! Just a few unquantifiable developers will use it, > but in the current configuration it endangers all BB systems by default. I accept that you may have a way to do this that I have not thought of, but I have yet to see you prove this. > > so there is no ways that Linus or his deputies would permit the removal of > this framework. > > Is it mainline? I thought it's a TI feature. Anyhow, mainline isn't affected. > This safety issue concerns boards with PRUSS, only. As I said before, on the BeagleBoard-x15, the DSP, CortexM4 and PRU all have access to the entire memory map, so loading firmware on any of these cores must be secure. It isn’t a PRUSS issue only. > > All you can do is attempt to make it better ... > > This is making it optional, or at least making PRUSS support optional in that > framework and disable it by default. Why, because your argument would apply to any processor, namely DSP, CortexM4, other ARM cores running a different OS or perhaps barebones, etc. As long as you need root access to load firmware onto these other cores, there is no security issue. > > so stop fighting a loosing battle and join me in fixing what you don’t like. > > That's a damed good idea. Since here we've to wait for a management decision, > why don't you use that time for fixing the issue from our March discussion? > Or at least answer the still open question > <https://groups.google.com/d/msg/beagleboard/ZTKntXOXGyc/GLBOQ2r5BQAJ>. > > BR Anyway, this discussion is not productive as we are not going to find a solution if you do not want to propose solutions. Your proposed solution of making RPMSG/RemoteProc optional isn’t a solution. However, perhaps there is a way to move the DT PRUSS definition into an DT overlay and not include the PRUSS definition in the base DT tree. This would allow both uio_pruss and RemoteProc to live side by side. Perhaps this is what you should be working on. I’m sure Robert Nelson would be open to a solution like this if you found a way to make this work.
Regards, John > > -- > 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/ee04b094-812b-43d8-b25a-5985a5fba148%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/ee04b094-812b-43d8-b25a-5985a5fba148%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 --- 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/A6AB98F5-F01A-437A-86DD-11ABDC34C9A8%40gmail.com. For more options, visit https://groups.google.com/d/optout.
