Firmware Developers Need To Know
Quick recap. This is the first blog in a long blog series diving into implementing cybersecurity for connected devices. Most advice for IoT cybersecurity will not mention error codes. And that is unfortunate, error codes are extremely valuable for disrupting threat actors dwell time – identifying covert subversions in the corners of the Internet. Your device’s error codes can act as a warning beacon for your customers.
TL;DR
- Error codes are potential indicator of a compromise.
- Eliminate pain by standardizing on error codes.
- Source code available.
NULL Pointer
The vast amount of code written for a connected device uses either a negative one (-1) or a NULL pointer to indicate a failure. On success, a zero (0) or non-NULL, valid pointer is returned. There was a time this all made sense, but today this is a sad state of affairs. Let’s reduce threat actors’ dwell time with better error codes. And debugging and support will be easier too.
if (OK > (status = MODULENAME_action(pContext, pData, dataLen)))
goto exit;
Tips
- Success is the most common return case; therefore, it should be easy to type and have a non-negative value. Error codes should be negative values.
- Error codes naming convention should be self-organizing and self-describing. e.g., ERR_TLS_HEARTBEAT_BAD_PAYLOAD_LEN or ERR_IKE_HANDSHAKE_VER_UNKNOWN or ERR_MEM_ALLOC_FAIL.
- Error codes should be grouped together ERR_TLS_*, ERR_TLS_HANDSHAKE_*, etc. Reserve space by padding for future group error codes.
- For ease of use, error codes, once officially released, should not be removed, relocated or relabeled.
- Error code values should be convertible to a string for pretty logging.
- Standardized error codes simplify cross-product documentation.
- Keep the error code list sorted for fast binary searches.
