The security logging module is responsible for logging audit, system, and Communications and Security Services related events. This topic focuses on event logging within the security partition.

Modules within the security partition, such as CAN and IP engines, make use of event logging to log records generated in accordance with the specified requirements for:

For example, the IP engine forwards each received packet to be scanned and based on the scan event results and the policy configuration, it may invoke the logging of such events.

Uploading the event log to the OTA server is required. This occurs when the event log reaches its maximum size, or at the middle of the day if it does not reach the maximum size.

In order not to overload the OTA upload folder in case of communication breakdown (for example, an IVC transfer issue), the OTA staging folder is set to a limited size (this is configurable and currently set to 5 * maximum file size of 5.24 MB).

If the file is due to be uploaded to the OTA staging folder and the new file size + total OTA size exceeds the maximum allowed folder size, then older files are deleted, and the new file is moved over.

When the log is uploaded, the filename is appended with the time and date, and the log file is saved to the OTA upload directory within the security service.

For example:

is moved to the Communication Service directory at:

For example, a time-stamped event log filename has the format:

If any log needs to be uploaded from Security VM on ad-hoc basis, make use of nvseccp (from the comms VM) or nvsecpush (from the security VM) applications.

nvseccp: In the comms VM, issue the following command:

If successful, the log file is copied to the comms VM under /userdata/transfers/ and the following is printed on the console:

nvsecpush: In the security VM, issue the following command:

If successful, the log file is copied to the comms VM under /userdata/otavmclient/upload/ and the following is printed on the console:

Once the log file is in the comms VM under /userdata/otavmclient/upload/, scp can be used to copy the file over the host PC:

The log file includes a header that describes each log entry as follows:

The header is followed by the actual logged data.

For example:

The logged data example provides a log from the Security Service firewall. the log entry is interpreted as follows:

FIREWALL -> Event Type (This can be any Packet scan service, such as Firewall, Deep packet inspection, Anti malware, etc.)

INFO: Severity

The actual message logged from the firewall is as follows:

Where:

The firewall event ID is as follows:

The firewall event code is as follows:

The CAN firewall event ID is as follows:

The CAN message frequency is as follows:

The CAN DPI is as follows:

The logging module implements a client server model with the client provided as a library to the modules that wish to log, such as IP or CAN. The implementation is performed by using the logging APIs.

Message queues are used to forward messages, such as log entries, from the client to the server. The logging server process, nvseclog_ser, is launched as part of the security startup script.

The logging server is responsible for:

To achieve logging of events, the logging client provides these APIs:

Where:

Event log entries are encrypted on-the-fly prior to being written to the event log files. Encryption of the event logs are achieved using the secure SEA engine. The resulting event log files are created in the security partition at:

If debugging is required, to read through, the files must be decrypted.

Since encrypted event logs are decrypted by the central OEM server, the decryption must be achieved on a host system NOT on the target hardware system. The secure engine AES is NOT available for decryption. Use OpenSSL to decrypt on the host Linux system.