Security review
What you would be approving, before anything installs.
For the security, platform or change control reviewer approving ADAPT on accelerators you own: what installs, what it listens on, what it reads and keeps, who changes an operating point, and how it comes off.
Deployment shape
One process per accelerator, under a restricted systemd unit.
- Process
- One daemon process per accelerator it controls, each a systemd instance started from a single unit template.
- Privilege
- Runs as root, held to two capabilities: CAP_SYS_ADMIN, which the vendor's management interface requires for clock control, and CAP_SYS_NICE for scheduling priority. The driver's device-control path needs that capability inheritable, so NoNewPrivileges stays unset; the read-only filesystem and denied tunables below still apply.
- Filesystem
- The root filesystem is read-only to the service, home directories are closed to it and its temporary directory is private. Writes are confined to /var/log/adapt, /var/log, /var/lib/adapt, /tmp/adapt, /run and /run/adapt.
- Operating system
- Changes to system tunables and the loading of modules are both denied to the service.
Network posture
Read-only answers over HTTP, and outbound paths off by default.
- Listening
- Each instance binds a metrics port and a health port. They answer GET requests for metrics, liveness and readiness, and return not found for anything else. Optional providers, such as a Redfish endpoint, are off by default.
- Authentication
- The metrics endpoint enforces a bearer token once you configure one, and logs a warning at start when none is set.
- Outbound
- Cloud synchronisation is a build option. Multi-node coordination, the dispatch and management console clients and the carbon feed are each off by default. The --airgapped flag switches off telemetry export, trace export, the carbon feed, multi-node coordination and the management controller poll.
- On the host
- Instances on one host share a state file under /run/adapt. Where a serving stack publishes a metrics endpoint on the host, the runtime reads it over loopback.
What it reads and keeps
Counters in, operating state and logs kept on the host.
- From the accelerator
- Through the vendor's management interface: power, compute and memory clocks, temperature, utilisation and memory occupancy.
- From a serving stack
- Aggregate counters from the stack's own metrics endpoint: generation throughput, requests in flight, cache occupancy and end-to-end latency.
- Kept on the host
- One log file per accelerator under /var/log, and a store of recognised workloads under /var/lib/adapt. A telemetry file for retraining, written locally under /var/lib/adapt by the launch wrapper's default. Sending it anywhere is a separate outbound path, listed under Network posture. The --airgapped flag switches off that export, and the local file with it.
- Kept when you name a path
- Learned calibration state, when a state directory is configured. A telemetry file, when one is named.
Who can change an operating point
Set in files on the host, by root.
- What reaches the hardware
- Locked compute clock targets through the vendor's management interface, and memory clock targets where that is enabled. Each tick's compute target passes a safety governor, which clamps it, then a thermal manager, which can release control. Optional finer adjustments stay inside a fixed band around that target, and memory targets inside a fixed floor and ceiling.
- Where it is set
- The clock floor, the control frequency and the operating mode are flags in the unit's drop-in. Under the unit, mode presets are read from /etc/adapt/modes.
- How it changes
- A file edit on the host, then a restart or a hangup signal to the instance. Both need root.
- Licence
- When a licence file is configured, the daemon checks it on the host against public keys before it starts. A licence that fails, has expired or covers fewer accelerators than the host has stops the start with a configuration error. The online check runs only when asked for.
What you can observe
The operating point, read on instruments you already run.
The metrics endpoint publishes, per accelerator, the clock it is running at and the operating mode in force, in the format a Prometheus-compatible stack scrapes.
The same clock state reads directly from the device with the vendor's own tools on the host, with nothing of ours in the path.
Service start and stop, for each instance.
Thermal emergencies and actuation failures, at warning level, for each accelerator.
Failure and release
Stopping the service releases the clocks.
- On a stop signal
- The daemon ends its control loop, joins its threads and resets the locked compute and memory clocks before the process exits.
- On a lost accelerator
- When the driver reports an accelerator lost, the runtime attempts to release that accelerator's clocks at once, and the vendor override below applies with nothing of ours in the path.
- Your own override
- Once an instance is stopped, the vendor's clock-reset commands, nvidia-smi -rgc and nvidia-smi -rmc, return the device to its defaults. Nothing of ours is in that path.
- Supervision
- systemd holds a 60 second keepalive window on every instance.
Removal
A written removal procedure, handed over with the unit template.
Nothing is deleted while a stop has failed or a clock reads back as held.
Stop and wait
Each instance is stopped and polled until it is inactive. A stop that timed out counts as a failure.
Read the clocks back
The clock state of each accelerator is read back before anything is removed.
Remove files
Files go only after every stop has completed and no accelerator reads back as still held. Configuration, state and logs stay unless you ask for them to go.
The procedure also reports the host's CPU frequency governor. Started outside the unit, where system tunables are not locked, the runtime sets that governor to performance; the removal procedure restores the value you name.
Your own baseline
Check the result with instruments you own.
Our measurement ran a managed arm and a baseline arm side by side under an equal power cap, reading GPU die power. The same design runs on your fleet with three instruments you already have.
Your own power query on a managed accelerator and an unmanaged one, over the same window.
Your serving stack's own throughput counter, read over that same window.
The clock state on the device, read with your own tools.
On request
What we hand your reviewer.
Each is sent for reading before anything installs.
- The systemd unit template and the launch wrapper.
- The written removal procedure and the removal script it describes.
- The software bill of materials for the runtime, in CycloneDX format.
Start the review
Say in the first line that you are reviewing ADAPT for security or change control.
Name the documents you want first.