Request for Arm Performix to publish to the snap store with classic confinement

  • name: arm-performix
  • description: Arm Performix is a performance profiling and analysis toolkit for optimizing performance-critical workloads on Arm-based systems. It profiles applications, collects system- and hardware-level metrics, and provides visualizations and guided insights for identifying CPU, memory, and system bottlenecks. This snap packages the Performix desktop UI together with its CLI. See https://developer.arm.com/servers-and-cloud-computing/arm-performix
  • snapcraft: PRIVATE
  • upstream: PRIVATE
  • upstream-relation: The snap is maintained and published by Arm, the upstream developer and vendor of Arm Performix
  • supported-category: debug tools
  • reasoning: Arm Performix must profile host processes and run arbitrary user-selected commands in their normal host environment. Strict confinement cannot support this workflow, so classic confinement is required.

YES: I understand that strict confinement is generally preferred over classic.

YES: I’ve tried the existing interfaces to make the snap to work under strict confinement.

1 Like

This request has been added to the queue for review by the @reviewers team.

Hi @armperformix,

Could you please provide more details to help me understand the application running arbitrary user-selected commands? Also, for profiling and metrics, have you tried interfaces like system-trace, hardware-observe, system-observe and what are the functionalities that were not achieved using the existing interfaces?

Hi @shishirsub10,

Those are fair questions - let me explain…

Performix supports “launch workload” profiling. The user can freely type in command to profile. It could be a compiled application, an interpreted script, a build-system target, a shell pipeline, or a command that launches further child processes.

Users can select the working directory, provide environment variables, and optionally run the command through their configured shell. Performix passes this command to the selected profiling collector, which then launches and profiles it. The executable, arguments, interpreters, shared libraries, configuration, input data, and child processes are therefore determined by the user’s workload and host environment.

This execution model is a platform-neutral part of Performix’s architecture. Performix supports Linux, macOS and Windows hosts, and supported targets include both Linux and Windows on Arm. The same workload model described above is used across all platforms.

Under strict confinement, a launched workload remains subject to the snap’s mount namespace, AppArmor policy and seccomp policy. Connecting an observation or tracing interface does not make the user-selected child process run in a host-integrated context. Arbitrary host executables may not be visible, and a workload or its children may be unable to access the host resources and system calls they normally require.

We evaluated the suggested interfaces:

  • system-observe is useful for reading process and system information and can address process enumeration.

  • hardware-observe provides read-oriented access to selected hardware information in /proc and /sys.

  • system-trace provides privileged tracing access and may address some kernel-tracing requirements of individual collectors.

However, none of these interfaces provides arbitrary host-command execution or removes strict confinement from the workload launched by Performix. Therefore, even if they satisfy all the data-collection requirements of a particular collector, the fundamental launch-workload workflow remains incomplete under strict confinement.

Our primary reason for requesting classic confinement is the required ability to launch arbitrary user-selected workloads, as described above.