Two technical questions towards GPU/CDI support: AppArmor and manifest capabilities

[LoudLemur]

We are working on a concrete, evidence-backed proposal for GPU (Graphical Processor Unit) device access for apps, following on from the long-running request in https://forum.cloudron.io/topic/12401 and the CDI (Container Device Interface) (groundwork described there.

The short version of the context: CDI has been enabled by default in Docker since 28.2.0, the docker-ce 29.6.2 that the current installer pins now routes even its own --gpus flag through CDI for both NVIDIA and AMD, and I have working proofs of a real GPU via CDI with the NVIDIA toolkit and of stock docker-ce 29.6.2 consuming a synthetic CDI spec through the same Engine API payload shape dockerode sends.

Writing the design up against the box source left us with a small number of questions that only Team Cloudron can answer:

Question 1: the docker-cloudron-app AppArmor profile.

A CDI spec injects host paths into the container at create time, typically the driver libraries and a few binaries such as nvidia-smi, as bind mounts described by the spec.

Does the docker-cloudron-app profile (setup/start/docker-cloudron-app.apparmor in the box source) permit reads and mmap of libraries mounted in from host driver paths, or would it deny them?

We can test this empirically on our own hardware if that is useful, but the profile's intended scope is something only its authors can state, and it determines whether a GPU grant works under the standard app confinement or needs a profile amendment.

Question 2: where manifest capabilities values are validated.

Reading the box source, manifest.capabilities appears to be consumed only in src/docker.js, with unrecognised values silently ignored, which would make adding a new capability name purely additive.

Is there a whitelist elsewhere, for example in the CLI's manifest validation or in app store submission checks, that would reject a manifest declaring an unknown capability such as gpu?

Question 3: which shape would you prefer, if any?

The two natural shapes I found are, first, widening the existing per-app Devices feature (the dashboard Resources form backed by setDevices) so it accepts CDI device names like nvidia.com/gpu=all alongside /dev/ paths, and second, a new manifest capability mirroring how vaapi is implemented, with a guard so it no-ops on hosts without a CDI spec.

The first reuses the persistence, REST, dashboard, audit and recreate machinery unchanged and keeps the decision with the administrator rather than the packager; the second matches the existing capability precedent.

If the team has a preference, or a reason both are wrong, knowing it before anything is written up further would save everyone time.

We have a full design sketch with source references, failure modes and non-goals, plus reproducible test transcripts, and are happy to share any of it; there is also an Nvidia machine available for any test the team would find persuasive.