Rambootin/CBCv3 Questions

Oh, you must be referring to the Kovan. ;)

1. Are you talking about the terminal in which the program executes (graphically), or something more like ssh/busybox? The latter is not stripped down.
2. Currently "Linux kovan 2.6.34 #1 PREEMPT Fri Jun 29 10:11:17 CDT 2012 armv5tejl GNU/Linux"
3. We are using a derivative of Ångstrom, which is in turn a derivative of OpenEmbedded. It is by no means generic, but OpenEmbedded's crazy awesome cross-compiler makes it a pleasure to work with and build packages for. We will be providing documentation on how to set up a build environment, but be warned, you'll need about 70GB of hard drive space, and an infinite amount of patience.
4. Nope, sorry.
5. Yes, any wireless card should work.
6. Something ATHEROS. It's not too important, since any card we've tested will work.
7. I think you'd have a hard time pulling over 800 mA on the USB ports. This is, however, to spec.

It should be noted, however, that user programs will be sandboxed (by default, and maybe as a rule during competition). This will prevent teams from turning on wifi in their programs. It is also much easier to brick the Kovan (due to a different upgrade procedure), so we are making that as hard as possible for the average team to do. Sorry, root access from user programs is going away. We are exploring alternatives that will allow installers and the like to be made by teams. It will probably be through the built-in graphical package manager.

I am very concerned about Braden's statement about sandboxing. I agree that sandboxing should be the default, since it makes bricking harder. However, KIPR has consistently ruled sandbox jailbreaks to be legal in the past (although recently KIPR has threatened to void warranties for it, which is reasonable). For example, KIPR explicitly ruled in 2007 that breaking out of the IC VM sandbox on the XBC was legal. They similarly ruled in 2009 that changing the CBOB's functionality was legal. And in 2011 (I may be off by a year), they ruled that running your own code on the Create was legal.

This freedom is, in my opinion, a very positive attribute of Botball, because it enables students to run wild with their imagination when it comes to adding their own functionality. Both Braden and I would not have received our Outstanding Conference Paper awards in Botball had this been illegal. In addition, I don't believe KIPR's time is best spent trying to secure a sandbox.

It has always been theoretically possible to cheat at the "remote controls are banned" rules, via IR, camera semaphores, and yes, wifi. To my knowledge, no team has ever even attempted this. This is mainly because such robots are visibly different in behavior, to the point that it is obvious that something shady is going on, and because teams just aren't that malicious. If they're determined to use a remote control, they would be competing in BEST or FIRST rather than Botball.

If KIPR is really determined to expend effort on making wifi cheating harder (which is unnecessary already), a better method would be to simply use a tool such as Wireshark to detect the wifi transmissions. (My guess is that YAC would be happy to assist in developing this effort.) This would be more secure than a sandbox, and wouldn't interfere with legal (non-wifi) hacking.

If teams were determined to cheat the system, they wouldn't have to use wifi anyway. IR is usable, and the use of OpenCV would make camera semaphores much more reliable and subtle. No team is likely to try to cheat the system, based on history.

So, in short, I highly recommend that KIPR not require sandboxing for tournament rounds. It has bad implications for hacking and other legal innovation, will not stop a hypothetical determined team, and is unnecessary given that no teams to date have been sufficiently motivated to cheat this way.

Allow me to clarify. There will be three tiers of sandboxing: Root, Normal, and Tournament. All three of these levels have different use cases:

• Root gives you complete root access to the device.
• Normal gives you complete access to the hardware of the device, but restricted filesystem permissions (your app will still have write access to a shared working directory.)
• Tournament restricts filesystem privileges and hardware privileges, namely wifi.

Even though "Tournament" must be turned on during competition, nothing prevents a team from entering "Root" before competition and modifying the firmware. For example, I could install CBCJVM or a mod package before competition, then use that package while my application is in "Tournament" during a match.

There are more subtle cases that wifi can be used to gain an edge:

• Communication between robots (something that will be trivial with our standard library)
• Post-game start configuration. Semi-autonomous control. (Their robot went left, use the left strategy.)

The other methods you listed do not have this subtlety factor, IMHO.

I agree that if someone was determined enough, the could definitely get wifi running during a tournament match. It will be extremely difficult, though. I believe this strategy makes it too complicated for most botballers to circumvent.

tl;dr Sandboxing does not prevent any hacking scenarios I can think of, and comes with good safety and game-time benefits.

Am I missing something? All of the leadership at KIPR believes that sandboxing should be implemented during tournament matches. If there is a use case that I'm not thinking of, however, I can implement it differently. (For example, add a Tournament with Root write permissions mode.)

Also, enabling "Root" mode will void a part of your warranty. This information is logged internally in the device.

Thanks.

Yes, this does alleviate most of my concerns. Since I haven't yet had a chance to play around with it, I don't really know exactly what use cases I would want. Having a tournament-legal mode which gives root write permissions without wifi might be useful for some teams.

I'm sure that the hackers will make requests during the season if this turns out to be too restrictive. As long as KIPR is reasonably responsive to these requests, I think this should be fine.

Thanks to KIPR for keeping it hackable. :-)

1.1 I meant the screen where the programs will run on the Kovan. Is there a full Linux terminal that can be accessed from the Kovan's touch screen interface? I know this was partly worked on for the CBCv2. This feature would be much appreciated. AKA can I type ls on the Kovan's touchscreen keyboard and see all the files in the current directory on the Kovan's screen (and get root access from this during non-tournament rounds)?

6.1 Do you know the exact chipset model? I'm sort of a wifi guy now.

8. When not sandboxed, is there a root password, and if so will KIPR provide it? As long as I have full root access while not competing (and maybe partial root access while competing?), I''ll be okay with the sandboxing as well.

9. Under tournament mode, can I still access the camera directly without going through KIPR's new vision system?

1. I will look into implementing a terminal emulator. Right now you could just kill X11 to expose a terminal.
6. Not off of the top of my head, sorry. I will ping Joshua for more info.
8. I will let you know when I implement Root mode. :P
9. I believe the only thing with modified permissions will be Wireless stuff, so I bet. OpenCV is exposed directly to C++ programs, however, so there is no need to circumvent our software in the first place. You should have access to every OpenCV module except opencv-nonfree.

10. Will the Kovan support the same create_write_byte (serial_write_byte) implementation as the CBC for create scripting?

Would it be possible to add custom sandbox modes in addition to the standard sandbox mode? I'm envisioning a sandbox where the user program can't access wifi, but a simultaneously running superuser program would have wifi access and expose it to the user program as FIFO's. (This would be useful in implementing things like semi-autonomous tournaments, where we only want the Kovan to have wifi access to certain hosts, subject to firewall rules which the user program can't change.)

Also, will any downloader that works with the CBC still work withthe Kovan?

11. Is the Kovan USB download cable really USB or does it go through a USB to serial converter inside the Kovan like the CBC did?