THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

USING A BOOT MONITOR IN EMBEDDED SYSTEMS

Part 2ıBuilding on the Basics
by Ed Sutter

Start ı The Ethernet Interface ı The Command Line Interface ı "Get Your Tokens Here" ı One Last Topic About CLI ı Executable Scripts ı Application-to-Monitor Hook-Up ı The Moncom() Function ı The Monconnect() Function ı Letıs Regroup ı Xmodem and Tftp ı OK, Iım Done! ı Sources and PDF

ONE LAST TOPIC ABOUT CLI

Recall that I mentioned earlier that the monitorıs CLI could be made accessible to the user interface of the application. This is good and bad. It is good because it keeps the monitor capabilities accessible when the application is up, allowing developers to do some "bare metal" stuff at the application command line without having to build it into the application (it just comes with the monitor). However, it also allows an end user to get at this same stuff. This means that the end user could modify RAM, erase flash memory, edit and remove files from TFS, and so on. These are things you may or may not want the user to have the ability to do.

The easiest solution here is to not provide the hook that allows the monitor commands to be accessible through the application, and in many cases this may be fine. On the other hand, the monitor has the concept of user levels, and each command can be set up so that it can be run only at or above a particular user level. The application can be running at a user level below the level required for certain commands in the monitor and only if the user level is raised will the commands be accessible. This provides a lot of flexibility and is simple to add to the CLI.

You need some way to store a configurable user level for each command plus a password facility of some kind. The user level for each command is stored in an array that is built alongside the command table array:

char cmdUlvl[(sizeof(cmdlist)/sizeof(struct monCommand))];

Note that this is separate because the command table array will be in ROM and this array must be in RAM.

The number of entries in this table will match the size of the command table, so this and the command table can be indexed the same way. If the third command in the cmdlist[] table is Add, then the required user level to execute the Add command will be stored in the third element of this table. By default, each commandıs user level is set to zero and the monitor is running at level three. A higher user level means more privileges, so this essentially means that all commands default to being accessible. A command in the monitor, ulvl, allows the user to reconfigure both the monitorıs running user level as well as the user level required to access each of the commands. Stepping down to a lower user level is granted without challenge. Stepping up to a higher user level requires a password.

Because the monitor has four user levels, there are three passwords needed, with level 0 not requiring a password. The ulvl command handles administration of the password file, and the password file is always stored at the highest user level, so it is inaccessible below user level four. Listing 5 is the code used to set up a commandıs user level. The input is a comma-delimited string containing the command name followed by the requested user level. Then there is the code that sets the new user level for a command and an example of a simple way to scramble a password for storage in a password file.

Notice that the ulvl command cannot have its user level changed. It must always be accessible without the need for a password. This is because you could otherwise trap yourself by making the ulvl command a level three command, then lowering the user level to three. After this is done, there is no way to get to level three again because you have to be at level three to use the ulvl command, but you need the ulvl command to get to level three. Around and around you go! Forcing the ulvl command to stay at level zero eliminates this catch-22.

Earlier I discussed user levels and the fact that they are password-protected. The passwords are stored in a file, which is set so it is readable only when the monitor is at user level three. An added protection is to scramble up the actual password prior to storage into the file. Then, the same scrambling algorithm can be used when someone enters the password, and the scrambled version of what the user enters is compared to what is in the password file. This is basically one-way encryption. Listing 6 is a simple example of the scrambling function.

The ulvl command uses these two functions for maintenance of the password file and for updating a commandıs user level. When the system is first booted, the monrc file can contain all of the ulvl commands needed to adjust the current monitor user level and the user level required to access certain commands.

PREVIOUS • NEXT