What's a good way to explain that system configuration at run time should not be changed by code at compile time? [closed]

Question

I am programming for a embedded system. When this system boots up it reads from a configuration file some data and execute rules to put the system state according to the configuration read. This configuration is dependent on the environment/requeriments of each customer and can be managed via management interfaces (as a Web interface).

Let me explain myself better: this embedded system is a home router (CPE) for ISPs. The configuration for the router is stored in a flash partition, and there is a default configuration file stored in the file system that is included in the firmware image. One of this ISPs has requested us to release a new firmware which should include a different configuration for one of the network interfaces used by the router.

The problem is this ISP does not want to perform a reset to default configuration file in his customers CPEs to not loose the configuration that each customer has saved on it (as the ESSID for the WLAN interface). The ISP wants the firmware to be able to connect using the new requirement for the network interface once the CPE has been upgraded.

One of my co-workers has proposed this: when the new firmware boots up, it checks if the interface exist in the CPE configuration and if not it adds it during boot time to the configuration file.

I would like to explain them (ISP and co-worker) using good reasons why the configuration file should not be modified at run time except by the management interfaces.

Answer 1

As this is basically the "Magic Number"-s '++' variant, a lot of the same arguments hold (or should, at least). To make a few of my immediate considerations fully verbal:

• Adding magic code for the purpose of changing a value is a high-maintenance procedure. Any change to the operation requires code-searches, verifications, re-compiles and re-flashing, whereas changing that value directly does not.
• Adding magic code can increase vulnerability. If done as a quick addition it can (read: will) either cause untested and/or unpredicted paths of execution, if it has to bind the interface this may even cause a short period of unprotected access with the addition of one single oversight, depending on the entire code of course.
• It's not good value for money. If you manage to eliminate the first two as arguments, you are spending a lot of time of a dedicated high-level developer on adding and changing features for problems that can be solved easier and cheaper.
• There are better alternatives to the problem posed.

My alternative, as per point 4: Design, add and test a module that can make a single incremental change to the configuration, using the same authentication and encryption you are using for other safe interfacing to the devices. Allowing the internals to copy-over the current configuration, but only changing that one configuration in the process, all locally, possibly in a non-responsive mode. This is an actual new feature, which if you design it well can remain safe, execution proven for all situations and can be used by a much lower-wage worker to reconfigure unrestricted parts of the set-up in years to come.

Of course you need to set some manner of boundaries as to what can be modified if you want the end-customer to remain safe in the knowledge nobody can reset their WiFi or router passwords to something else.

---

All that said, my personal experience with ISPs and 9 out of 10 of the companies that build their firmware in general is similar to yours: The ideology of "just throw this in there and compile" still reigns. This is in fact a large driving force these days in choosing my ISP, over cost and speed, as I prefer reliability.

Working with others in embedded systems can be a mine-field :-)