[RFC] Proposal for a standard Competitive / Protected Session API in Linux

From: 洛神葵

Date: Fri Sep 25 2026 - 05:15:09 EST


Hello,

I would like to propose an idea for a Linux API intended for
competitive games, online games, and potentially other applications
that require a high-integrity execution environment.

Linux already provides a number of relevant security mechanisms,
including ptrace restrictions, process memory access controls, LSM,
Secure Boot, kernel lockdown, and kernel module signing.

However, these mechanisms are currently exposed separately. A game
that wants to establish a trusted competitive environment may need to
detect and combine several different mechanisms on its own.

I would like to ask whether it would make sense to provide a unified
Protected Session / Competitive Session API.

The basic model could be relatively simple.

When a game starts, it requests a protected session, for example:

competitive_session_create(...)

The kernel checks whether the current environment satisfies the
requested protection level and returns something similar to:

ALLOWED: the environment satisfies the requested requirements;

DENIED: the environment does not satisfy them, together with a
standardized reason.

While the protected session is active, Linux would protect processes
belonging to that session from unauthorized interference.

For example, depending on the selected protection level, this could
restrict other processes from:

debugging or attaching to the protected process through ptrace;

reading or modifying its process memory;

obtaining sensitive information through /proc;

using other kernel interfaces to observe or interfere with the
protected process.

The exact interfaces covered by such a mechanism would of course need
further discussion.

The game may explicitly terminate the protected session:

competitive_session_close(...)

Normal system behavior would then be restored.

If the game crashes, is terminated, or the protected process exits,
the session should automatically be destroyed by the kernel.

This would ensure that the system cannot accidentally remain in a
competitive/protected state if the application fails to shut down
cleanly.

A major advantage of this model is that game developers would not need
broad permission to scan the user's system, inspect unrelated files,
or monitor every other application.

Instead, Linux itself would establish and enforce the protected environment.

The game would only need to know:

"Does the current system satisfy the requirements for this protected session?"

In other words, the API would provide a trusted execution environment
for the application rather than granting the application broader
system-monitoring privileges.

A simplified lifecycle would look like this:

Game starts
|
v
Request Protected Session
|
v
Linux checks the environment
|
v
ALLOWED / DENIED
|
v
Game enters competitive mode
|
v
Game exits or explicitly closes the session
|
v
Protected Session is automatically destroyed

My main questions are:

Does Linux already provide a unified interface with similar semantics?

If not, would a Protected Session abstraction like this be worth
discussing as a generic userspace API?

Competitive gaming is the most obvious use case, but such a mechanism
could potentially also be useful for other applications that need
stronger protection of their process integrity or confidentiality, so
I do not think it necessarily needs to be designed as a game-specific
API.

Thank you.