In principle, being a mere ROM module, a component configuration can come in an arbitrary format. However, throughout Genode, there exists the convention to use XML as syntax and wrap the configuration within a <config> node. The definition of sub nodes of the configuration depends on the respective component.

Servers that serve multiple clients may apply a different policy to each client. In general, the policy may be defined by the session arguments aggregated on the route of the session request as explained in Section Services and sessions. However, in the usual case, the policy is dictated by the common parent of client and server. In this case, the parent may propagate its policy as the server's configuration and deliver a textual label as session argument for each session requested at the server. The configuration contains a list of policies whereas the session label is used as a key to select the policy from the list. For example, the following snippet configures a RAM file system with different policies.

 <config>
   <!-- constrain sessions according to their labels -->
   <policy label="shell -> root" root="/" />
   <policy label="shell -> home" root="/home/user" />
   <policy label="shell -> tmp"  root="/tmp" writeable="yes" />
 </config>

Each time a session is created, the server matches the supplied session label against the configured policies. Only if a policy matches, the parameters of the matching policy come into effect. The way how the session label is matched against the policies depends on the implementation of the server. However, by convention, servers usually select the policy depending on the attributes label, label_prefix, and label_suffix. If present, the label attribute must perfectly match the session label whereby the suffix and prefix counterparts allow for partially matching the session label. If multiple <policy> nodes match at the server side, the most specific policy is selected. Exact matches are considered as most specific, prefixes as less specific, and suffixes as least specific. If multiple prefixes or suffixes match, the longest is considered as the most specific. If multiple policies have the same label, the selection is undefined. This is a configuration error.

As described in Section Read-only memory (ROM), a ROM module can be updated during the lifetime of the ROM session. This principally enables a parent to dynamically reconfigure a child component without the need to restart it. If a component supports its dynamic reconfiguration, it installs a signal handler at its "config" ROM session. Each time, the configuration changes, the component will receive a signal. It responds to such a signal by obtaining the new version of the ROM module using the steps described in Section Read-only memory (ROM) and applying the new configuration.