# MVGAL Security Review

**Date:** 2026-06-01  
**Status:** Internal Review (Draft)

## Overview

MVGAL (Multi-Vendor GPU Aggregation Layer) coordinates heterogeneous GPUs at both the kernel and user-space levels. This document outlines the security architecture, threat model, and mitigation strategies implemented in the system.

## Security Architecture

MVGAL employs a layered security model:

1.  **Kernel Boundary (`mvgal.ko`)**: Minimal attack surface, strictly validated ioctls.
2.  **Rust Safety Layer**: Memory safety for fence and memory tracking logic.
3.  **Daemon Isolation (`mvgald`)**: Runs as a dedicated service, restricted IPC.
4.  **Privilege Escalation**: Uses `pkexec` (Polkit) for all privileged operations.

## Kernel Security

### IOCTL Validation

All ioctls in `/dev/mvgal0` undergo rigorous validation:
- **Range Checking**: All indices and offsets are checked against actual device counts and buffer sizes.
- **Copy Protection**: `copy_from_user` and `copy_to_user` are used for all data transfers.
- **Permission Checks**: Writing ioctls (workload submission, memory allocation) require `CAP_SYS_ADMIN` or membership in the `video` group.

### DMA-BUF Safety

MVGAL uses standard Linux DMA-BUF mechanisms for cross-GPU memory sharing. 
- Access is restricted to processes that have valid file descriptors for the DMA-BUFs.
- MVGAL does not bypass kernel-level DMA-BUF isolation.

## IPC Security (`mvgald`)

### Authentication

The `mvgald` daemon uses a Unix domain socket (`/run/mvgal/mvgal.sock`) for communication.
- **SCM_CREDENTIALS**: The daemon uses `getsockopt(SO_PEERCRED)` to verify the UID and GID of the connecting process.
- **Access Control**: Only the `root` user and members of the `video` group are permitted to submit workloads or change system-wide configurations.

### Message Validation

- All IPC messages have a fixed-size header with a magic number and version.
- Payload sizes are strictly validated before processing to prevent buffer overflow or memory exhaustion attacks.

## Rust Safety Subsystems

The Layer 2 safety subsystems are implemented in Rust to eliminate common memory safety vulnerabilities:
- **Fence Manager**: Prevents double-signaling or use-after-free of synchronization primitives.
- **Memory Safety**: Reference counting and lifetime tracking for cross-GPU allocations.
- **FFI Boundary**: Strictly audited `extern "C"` interfaces with `catch_unwind` to prevent panics from crossing the FFI boundary.

## Privilege Management

MVGAL avoids the use of `sudo` in scripts.
- **Polkit/pkexec**: All operations requiring elevated privileges (e.g., loading kernel modules, setting power limits) are triggered via `pkexec`.
- **Action Policies**: Polkit policies define exactly which operations are allowed and who can perform them.

## Threat Model & Mitigations

| Threat | Mitigation |
|--------|------------|
| Unauthorized Workload Submission | `SCM_CREDENTIALS` authentication on Unix socket. |
| Denial of Service (Memory Exhaustion) | Per-process and global memory limits in `mvgald`. |
| Cross-GPU Data Leakage | Strict adherence to DMA-BUF ownership and permission models. |
| Kernel Panic via Malformed IOCTL | Comprehensive input validation and fuzzed IOCTL interface. |
| Privilege Escalation via Daemon | Daemon drops unnecessary capabilities after initialization. |

## Vendor Driver Boundaries

MVGAL sits *above* vendor drivers (NVIDIA, AMD, Intel, MTT).
- It does not interfere with vendor-specific security features (e.g., NVIDIA GSP, AMD PSP).
- It relies on the security of the underlying DRM/KMS stack for physical hardware access.

## Compliance

- **License**: Kernel module is GPL-2.0; userspace is MIT.
- **Privacy**: No telemetry is sent outside the local system unless explicitly configured by the user (e.g., Prometheus exporter).
