Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode

[Marwan Seliem <marwanmhks@gmail.com>]

Let me clarify the security rationale and address your concerns.

> "security" involves crashing the system, so I fail to understand why one
> is more "secure" than the other.

You're absolutely right that crash access itself requires careful consideration. 
The security distinction we're making is between:

1. Controlled Crash Access (our patch):
   - Single, auditable code path (only sysrq-c)
   - No runtime configuration possible
   - No ancillary debug features that could leak information

2. Full SysRq Access:
   - ~60 command vectors to maintain/audit
   - Runtime configuration complexity
   - Features like memory/register dumps

> I don't understand your graphs here, what are you trying to say?
> Somehow still allowing someone to crash the system still is "secure"?

Apologies for the unclear visualization. The key points are:

1. Current reality forces a binary choice:
   - CONFIG_MAGIC_SYSRQ=n: No debug capability
   - CONFIG_MAGIC_SYSRQ=y: Full command set

2. Our proposal adds:
   CONFIG_MAGIC_SYSRQ_CRASH_ONLY=y:
   - Only sysrq-c enabled
   - All other commands compile-time disabled
   - No runtime reconfiguration possible

The security value comes from:
- Reducing attack surface from ~60 commands to 1
- Eliminating information leaks (register/memory dumps)
- Preventing privilege escalation vectors (like filesystem control)
- Meeting compliance requirements that mandate crash access
  while prohibiting other debug features

> confused,

This isn't about claiming crashes are "secure", it's about providing the minimal 
debug capability required by certain industries while eliminating all other 
sysrq-related risks.


Marwan Seliem