Carbide.ct Validation
Introduction
The article lists validations that are implemented as part of Carbide.ct. Tool validations replace the current excel based central repository SCB CR process.
The tool will report some new errors and warnings that have not been shown before. In other words, the rules for acceptable data have been tightened to ensure the quality of the confml and crml specifications. However, it is usually a simple matter to correct the reported errors and warnings.
In some rare cases, it may be necessary to allow exceptions to the rules. The owners of the confml and other ml data are responsible for the decisions about the exceptions. The exceptions should be listed in a separate table as explained here. The S60 Configurability Program will follow the situation and later decide, if some mechanism is needed to permanently mark up the exceptions so that the tools would not even report certain errors on certain data.
Central Repository Key validations
Capability Checks and RFS / Backup Checks represent common problems in defining central repository key capabilities, read-onlyness, backup-restore and Restore Factory Settings -property. Not following the rules may make it impossible to
- share settings between components,
- enable some other component to change a read-only setting in a harmful way,
- make the backup-restore operation or the RFS operation to fail on some componet.
The owner of the settings is responsible for defining these properties. The owner is also responsible for any exceptions that he/she makes to these rules. To help the owners in keeping the setting definitions in a valid state, Carbide.ct has the capability to check cenrep key definitions against these rules and warn the user about violations.
Error classification
The rules are divided in two categories: Errors and Warnings. This categorization is based on the experience with these issues since the introduction of Platform Security to S60 SW. Errors represent situation that may risk system integrity. Warnings are less severe situations but they may still cause problems. So, take both seriously and aim to remove all errors from your cen rep key definitions.
Exceptions
Other validations
Misc Checks contain validation rules for other errors in confml and implementation-ml (e.g. crml) data.
Notation
{%element%}
Definition of {%element%} depends on context; basically it is one of the following:
- Repository
- Key
- Range
- Bitmask
{%ref%}
{%ref%} means unique reference to an element, format being element specific:
- For repository, ref has format "Uid Value (Uid Name)" => e.g. "0x10207218 (KCrUidAknFep)". If Uid Name does not exist, plain Uid Value is shown.
- For keys, bitmasks, ranges and confML settings, ref stands for element reference => e.g. "KCRUidConnectionUiUtilities/KConnectionUiUtilitiesScanInterval"
{%element_ref%}
{%element_ref%} = {%element%} + {%ref%}
Example: "Key KCRUidConnectionUiUtilities/KConnectionUiUtilitiesScanInterval"
Capability Checks
{%element_ref%} does not have any read capabilities
Classification:
Warning
Description:
{%element%} does not contain any read capabilities. This effectively means that capability check will always fail. In case the intention is to specify no need to have any capabilities to access the information, AlwaysPass capability should be used.
{%element_ref%} read capability differs from AlwaysPass or ReadDeviceData
Classification:
Warning
Description:
Read capability differs from AlwaysPass or ReadDeviceData. By default, read access to any key must be allowed unless the data is really secret. Only things like passwords for e- mail accounts and network access points are really secret. Secret data should then be protected by ReadDeviceData only.
If some data really needs to be protected by ReadUserData, it should not be stored in central repository in the first place. Central Repository is meant for storing device settings.
Note that the read and write capabilities can be asymmetric. For example, changing Profile settings should be protected by WriteDeviceData. On the other hand, everybody should be able to read Profile settings at any time, so the read capability should be AlwaysPass.
In case there really is need to use other read capabilities, please document the case to the Exceptions table.
{%element_ref%} has other read capabilities defined with AlwaysPass
Classification:
Error
Description:
AlwaysPass capability defines that there is no need to have any capabilities to access the information. However other capabilities are marked for given {%element%}.
{%element_ref%} is read-only, but also write capabilities are set
Classification:
Warning
Description:
In case {%element%} is marked read-only, no write capabilities are allowed.
Notes:
This rule is not applied to repositories (only to keys, bitmasks and ranges). Repository cannot be read-only.
{%element_ref%} write capability is neither AlwaysPass nor WriteDeviceData
Classification:
Warning
Description:
If there is any write access marked to an element, in most cases it should be either AlwaysPass or WriteDeviceData. In case of write protection, most often (in ~99.9% of the cases) element has WriteDeviceData capability (and not e.g. WriteUserData).
It must be ensured that an application without any capabilities can do basic things (e.g. write to screen, use T9...). On the other hand, critical or secret setting data must be well protected.
Writable {%element_ref%} does not have any write capabilities
Classification:
Warning
Description:
{%element%} does not contain any write capabilities, even though it is writable. This effectively means that capability check will always fail. In case the intention is to specify no need to have any capabilities to write the information, AlwaysPass capability has to be used.
Note: a SID is considered as a capability. So, it is not an error, if the writing of the key is protected only by one SID and nothing else.
{%element_ref%} exceeds capability amount limitations
Classification:
Error
Description:
There is restriction on amount of capabilities. There can be maximum 7 capabilities OR 1 SID + 3 capabilities defined for single check (either read or write).
Note the relationship between capabilities and SID + capabilities:
- If several capabilities are required, they all are needed to access the value of the {%element%} (Capability1 AND Capability2 AND Capability3 AND ...).
- If the SID and capabilities are marked, either the SID or all the marked capabilities are needed to access the value of the key (SID OR Capability1 AND Capability2 AND ...).
RFS / Backup Checks
Back-up is enabled for {%element_ref%}, but repository misses owner definition
Classification:
Error
Description:
{%element%} is marked to be backed up, but the owner definition (Secure ID, SID) of the repository is missing. Owner information is needed for back-up to succeed.
Read-only {%element_ref%} is marked for RFS
Classification:
Warning
Description:
Restore Factory Settings must not be enabled for read-only {%element%}, and will be ignored during initialization file generation.
Read-only {%element_ref%} is marked for backup
Classification:
Warning
Description:
Backup must not be enabled for read- only {%element%}.
{%element_ref%} has RFS defined, but write capability is missing
Classification:
Warning
Description:
Restore Factory Settings (RFS) works in case of central repository keys so that if all the keys inside repository have RFS set, then the RFS will be done calling the ResetAll() -method in the central repository API. This method checks the repository specific write capability.
If not all the keys have RFS set, then the Reset() method is called on each key separately. This method checks the capabilities defined for each key. In this case, the write capability of the repository is not checked.
If the repository/key specific write capability is AlwaysPass, anybody (including 3rd party software) can make RFS to your repository/key. If write capability is not defined, RFS won't work at all since the default capability check will fail.
In general, specifying a SID as a capability is enough. However, if RFS is defined, it is wrong to define a SID as the write capability. See the next rule.
{%element_ref%} has RFS defined, but write capability is restricted with SID
Classification:
Warning
Description:
Restore Factory Settings (RFS) works in case of central repository keys so that if all the keys inside repository have RFS set, then the RFS will be done calling the ResetAll-method in the central repository API. This method checks the repository specific write capability.
If not all the keys have RFS set, then the Reset method is called on each key separately. This method checks the capabilities defined for each key and the repository write capability is not checked.
If the repository/key specific write capability is restricted with SID, RFS won't work at all since the default capability check will fail.
Misc Checks
Path identifier {%ref%} uses incorrect directory separator marks
Classification:
Warning
Description:
Directory separators in file paths should be two backslashes ( "\\" ).
Notes:
In case string begins with "c:" or "z:", string is considered to be a file path. Confml also supports file and folder datatypes.
No value defined for a setting {%ref%}
Classification:
Error
Description:
Integer, real and boolean settings must always have a value defined.
{%element_ref%} ID not in hexadecimal format
Classification:
Error
Description:
Repository UID must be in hexadecimal format. The same applies to key, range and bitmask identifiers.
KeyRange element {%element_ref%} does not contain firstInt / lastInt definition
Classification:
Error
Description:
KeyRange definition misses firstInt or lastInt definition. Both are required.
Writable setting {%element_ref%} does not contain any documentation
Classification:
Warning
Description:
Writable settings are modified by several parties. Proper modification requires sufficient documentation.
Notes
Location area might have potential case, which conflicts with RFS & back-up read-onlyness rules. Possibly something to do with post-sales scenarios. Needs to be checked from sheets / location team if that is the case.
In any case, rules must be validated against existing confmls/crmls before deployment, to check message validity and to create potential exceptions.