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

Hello,

Thank you for the reply. After thinking about it again, I realized
that my original proposal mixed up two different layers: the
competitive policy of a gaming platform, and the generic mechanisms
that the Linux kernel should provide.

I now think that a Competitive Mode / Competitive Session would be
better implemented by a distribution or gaming platform such as
SteamOS, rather than being defined directly by the Linux kernel.

For the Linux kernel itself, I think there may only be two generic
capabilities worth considering.

First, a unified and stable interface for userspace to obtain factual
information about the current security state of the system, such as
the boot chain, kernel integrity, module state, and other relevant
security properties.

Linux itself would not decide whether the system is "trusted". It
would only report the relevant facts.

SteamOS or another platform could then define its own Competitive
Profile based on those facts, and a game could decide whether it
accepts that profile.

Second, a unified Protected Process / Protected Process Group semantic.

The purpose would simply be to allow a process to request stronger
isolation from unrelated processes that might observe, read, modify,
debug, or otherwise interfere with its internal state.

This should not take ultimate control of the machine away from its
owner. The user should still be able to disable the protection, debug
the process, or modify their own system. The upper layer would simply
be able to determine that the protected state is no longer valid.

The resulting model could therefore be quite simple:

Linux Kernel:
- provide a unified interface for security-state information;
- provide a unified Protected Process primitive.

SteamOS / Game Platform:
- build a Competitive Session on top of those mechanisms;
- define its own competitive security policy.

Game:
- decide whether the current environment is acceptable for ranked or
competitive play.

For the ordinary competitive-gaming threat model I had in mind, I also
do not think it is necessary to immediately use a
confidential-computing environment such as SEV-SNP or TDX. That seems
more appropriate for a stronger threat model.

Thanks again for the feedback.

Serge E. Hallyn [off-list ref] 于2026年9月25日周五 21:06写道：

On Fri, Sep 25, 2026 at 05:14:46PM +0800, 洛神葵 wrote:

quoted

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.

Why would they need to do that anyway?  What are you protecting them
from exactly?  Cheating?  Secret stealing?  Playing without a license?

This sounds like us going out of our way to enable proprietary software
to lock us down to protect their "rights" - DRM.

I guess what you're promising us is that "this way you won't be forced
to run crowdstrike and tenable and intune to be able to play these games".
But 1. I still prefer to say "then nobody *needs* to play these particular
games", and 2. I could just compile my own kernel with
competitive_session_create() being a noop, so you'd still be digging
around to make sure I didn't do that, right?

quoted

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?

I think the closest you could come today is to run it in a
confidential computing VM like SEV-SNP/TDX.

quoted

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

Possibly, but the first objection you'd have to overcome is that
you are asking us to reduce our rights on the hardware and software
that we own.  E.g. not being able to strace to figure out what is
missing when the software isn't working - yuck.

quoted

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.