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

[Serge E. Hallyn]

On Fri, Sep 25, 2026 at 05:14:46PM +0800, 洛神葵 wrote:
> 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?

> 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.

> 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.

> 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.