---
title: "Appendix: Apple Silicon System Configuration"
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/appendix_systemconfig
---

# Appendix: Apple Silicon System Configuration

A node’s configuration parameters.

## Overview

Overview The darwin-init process implements a policy to limit which configuration it will apply in customer security mode. The policy summaries on this page are for reference and illustration; the authoritative policy is the one darwin-init implements. Policy implementation darwin-init implements configuration policy using Rego, a policy language from the Open Policy Agent (OPA) project. Rego enables darwin-init to express validation rules as declarative statements rather than procedural code. When applying a configuration, darwin-init loads the policy bundle from /usr/share/misc/darwin-init_validator_bundle and evaluates the configuration against the rule set for the configured security mode. The node’s attestation covers these rules, because the bundle’s path is part of the immutable Signed System Volume. note: Rego Policy Source Rego Bundle PCCRegoValidator Validation flow When darwin-init receives a configuration, it follows this validation process: Parses the JSON configuration into a Swift struct representation to be applied if validation succeeds. Serializes the Swift struct back to JSON and passes it to the embedded OPA engine to evaluate the JSON against the policy loaded for the current security mode. Parses the validation result from the OPA engine and logs any policy violations. If validation fails, darwin-init rejects the entire configuration array and takes its failure action, rebooting the node or exiting. darwin-init initiates entry into Restricted Execution Mode (REM) only as its last step, after it applies every configuration, so a node whose configuration fails validation stays outside REM. Its attestation reports that state, and Node validation rejects the node. A rejected configuration still leaves a record in that attestation: darwin-init registers the merged secure-config parameters with secureconfigd before it validates, so their values are sealed into the Configuration Seal Register. Validation fails if a configuration violates any of the following policies. Top-level keys For the top-level keys, darwin-init prohibits any configuration that is not in accordance with the policy described:  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |  Secure config keys The customer policy enforces the following restrictions on secure-config keys:  |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |  The customerProxy policy enforces the same policies as the customer policy, with the following exception:  |  |   |  |  CFPrefs domains The customer and customerProxy policies allow setting preferences in the following CFPrefs domains:  |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
