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 1. Security 2. Speed 3. 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 1. General direction 2. Milestones 3. 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 --- 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/106e6bd3-c256-4429-bd7f-ebac5a9f9c8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
