@TJF 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. In addition, you should reframe from impugning a person's motivations or intentions. 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. No one knows how many developers are using RemoteProc/RPMSG, so there is no ways that Linus or his deputies would permit the removal of this framework. All you can do is attempt to make it better, so stop fighting a loosing battle and join me in fixing what you don’t like.
Regards, John > On Jun 29, 2016, at 12:46 AM, TJF <[email protected]> wrote: > > Good morning John! > > Am Dienstag, 28. Juni 2016 17:48:24 UTC+2 schrieb john3909: > It is hard to keep up with your changing priorities. > > My priorities are > Security > Speed > Resources > That didn't change for years. > > What you mean is that my focus changed in this discussion. Before that > discussion, I didn't know much about that framework. I read just enough to > find out that it doesn't adress my needs, too slow, too bloated. Then, in > this discussion, I learned more about the project and its features, and I > found out that it also doesn't adress my first priority. So I changed my > focus from minor to major priority. Since we're now at the highest priority, > there wont be any further changes. > > Addressing your security issues, you never answered my original question. How > are you going to install PRU firmware ... > > I wrote it several times, libpruio uses libprussdrv to load the firmware. > > This is what makes the PRU secure. Without root permission, you cannot > replace the PRU firmware, period. > > Period? A standpoint is an intellectual horizon with the radius null. > > An agressor needs physical access to the system, but no root permission on > that system. > When the BB boots from SD card, the agressor puts this card in his laptop > where he has root permission to copy the malware to > /lib/firmware/am335x-pru$[0|1]-fw on the SD partition. > When the BB boots from EMMC, the agressor inserts a bootable SD card and > presses the boot button on start up. The system boots from SD and it neither > needs a monitor nor a keyboard, the copy process can get executed by a boot > script to place the malware on the EMMC partition. > Welcome to reality! > > Sure, any virus can get installed that way. But why should it be more easy to > install a worst case kernel virus than to install a simple userspace malware? > An why should the operationg system help to get it running? > > You originally claimed that RemoteProc/RPMSG was bloated and slow, so I > proposed a solution to address this issue by using zero copy techniques, but > now this is no longer important to you. > > This is a proposal on a detail. Currently it makes no sense to work on > details. At the moment, it needs a management decision > General direction > Milestones > and then your important detail work. > It sounds like you are only interested in getting libpruio into mainline ... > > Is this a bad scenario? Yes, because due to all that kernel changes I'd have > to spend a lot of effort to keep it up to date. > > What about you? You insists on keeping that framework in mainstreams default > configuration, although you know that you could use it as an optional package > as well. Why? This sounds like you're planing to use this weak point for your > next malware. This sounds like you want to become an author of a Linux kernel > virus. > > But instead of listening to mystic sounds, we both should concentrate on > facts and arguments. > > 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/106e6bd3-c256-4429-bd7f-ebac5a9f9c8b%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/106e6bd3-c256-4429-bd7f-ebac5a9f9c8b%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/ACDCAFB1-20CD-4CC2-A83B-9E118A249402%40gmail.com. For more options, visit https://groups.google.com/d/optout.
