* [PATCH] tty: sysrq: Introduce compile-time crash-only mode
@ 2025-06-07 15:19 Marwan Seliem
2025-06-09 7:48 ` Jiri Slaby
2025-06-11 6:33 ` Marwan Seliem
0 siblings, 2 replies; 6+ messages in thread
From: Marwan Seliem @ 2025-06-07 15:19 UTC (permalink / raw)
To: gregkh, jirislaby; +Cc: akpm, linux-kernel, linux-serial
This commit introduces a new Kconfig option, CONFIG_MAGIC_SYSRQ_CRASH_ONLY,
which allows for a significant hardening of the system by restricting
the Magic SysRq functionality at compile time.
Security Impact:
- Reduces attack surface by disabling non-essential SysRq commands
- Maintains critical crash-dump capability required for debugging
- Eliminates runtime configuration vulnerabilities
When CONFIG_MAGIC_SYSRQ_CRASH_ONLY is enabled:
1. Restricted Commands: Only the 'c' (trigger a system crash/dump)
SysRq command remains operational. All other built-in SysRq commands
(e.g., reboot, sync, show-memory, SAK) are disabled.
2. Runtime Registration Disabled: The kernel will no longer allow
the registration of new SysRq key operations at runtime via
register_sysrq_key(). Attempts to do so will return -EPERM and
a warning will be logged.
3. Crash Command Unregistration Prevented: The 'c' (crash) command
cannot be unregistered at runtime if this Kconfig option is active.
4. Proc Interface Hardening: The /proc/sys/kernel/sysrq interface,
which normally allows runtime enabling/disabling of SysRq features,
is effectively neutered for non-crash commands.
- Writing to /proc/sys/kernel/sysrq to enable features other than
the crash dump will be blocked (returns -EPERM with a warning).
- The sysrq_on_mask() function, which checks if a specific SysRq
operation is permitted, will only return true for the crash dump
operation, regardless of the /proc/sys/kernel/sysrq bitmask or
the sysrq_always_enabled kernel command line parameter.
5. Restricted Help Output: When an invalid SysRq key is pressed, the
help message printed to the console will only list the 'c' (crash)
command, reflecting the restricted functionality.
6. Compile-Time Table Modification: The sysrq_key_table is
initialized at boot time by sysrq_init_crash_only_table() to
contain only the sysrq_crash_op for the 'c' key. All other
entries are set to NULL.
This feature provides a strong compile-time mechanism to reduce the
attack surface associated with the Magic SysRq key, limiting its use
to critical crash dump generation for debugging purposes, which is often
essential even in highly secure environments.
The sysrq_on() function is modified to always return true when
CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. This ensures that the SysRq
input handler is registered, allowing the Alt+SysRq+C key combination
to be processed, while the actual command filtering occurs deeper
within the SysRq logic.
Usage Recommendation:
For systems requiring:
1. Guaranteed crash-dump capability
2. Elimination of debug backdoors
3. Compliance with strict security requirements
Affected files:
lib/Kconfig.debug: Added CONFIG_MAGIC_SYSRQ_CRASH_ONLY.
drivers/tty/sysrq.c: Implemented the conditional logic
for restricted mode.
Signed-off-by: Marwan Seliem <marwanmhks@gmail.com>
---
drivers/tty/sysrq.c | 79 ++++++++++++++++++++++++++++++++++++++++++++-
lib/Kconfig.debug | 13 ++++++++
2 files changed, 91 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 6853c4660e7c..2e574380bec4 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -61,7 +61,18 @@ static bool __read_mostly sysrq_always_enabled;
static bool sysrq_on(void)
{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ /*
+ * In CRASH_ONLY mode, sysrq is considered "on" only for the purpose
+ * of allowing the crash command. The actual check for individual
+ * commands happens in sysrq_on_mask().
+ * For general "is sysrq on?" queries (like for input handler reg),
+ * it should reflect that at least something (crash) is possible.
+ */
+ return true;
+#else
return sysrq_enabled || sysrq_always_enabled;
+#endif
}
/**
@@ -82,9 +93,19 @@ EXPORT_SYMBOL_GPL(sysrq_mask);
*/
static bool sysrq_on_mask(int mask)
{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ /*
+ * If CRASH_ONLY is set, only allow operations that have the
+ * SYSRQ_ENABLE_DUMP mask (which sysrq_crash_op uses).
+ * This makes sysrq_enabled and sysrq_always_enabled irrelevant
+ * for other operations.
+ */
+ return mask == SYSRQ_ENABLE_DUMP;
+#else
return sysrq_always_enabled ||
sysrq_enabled == 1 ||
(sysrq_enabled & mask);
+#endif
}
static int __init sysrq_always_enabled_setup(char *str)
@@ -557,6 +578,21 @@ static int sysrq_key_table_key2index(u8 key)
}
}
+/*
+ * Initialize the sysrq_key_table at boot time if CRASH_ONLY is set.
+ * This ensures only the crash handler is active.
+ */
+static void __init sysrq_init_crash_only_table(void)
+{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ int i;
+ const struct sysrq_key_op *crash_op = &sysrq_crash_op;
+ for (i = 0; i < ARRAY_SIZE(sysrq_key_table); i++)
+ sysrq_key_table[i] = NULL;
+ sysrq_key_table[sysrq_key_table_key2index('c')] = crash_op;
+#endif
+};
+
/*
* get and put functions for the table, exposed to modules.
*/
@@ -584,7 +620,6 @@ void __handle_sysrq(u8 key, bool check_mask)
{
const struct sysrq_key_op *op_p;
int orig_suppress_printk;
- int i;
orig_suppress_printk = suppress_printk;
suppress_printk = 0;
@@ -599,7 +634,15 @@ void __handle_sysrq(u8 key, bool check_mask)
*/
printk_force_console_enter();
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ if (key != 'c') { /* In CRASH_ONLY mode, only 'c' is considered */
+ op_p = NULL;
+ } else {
+ op_p = __sysrq_get_key_op(key);
+ }
+#else
op_p = __sysrq_get_key_op(key);
+#endif
if (op_p) {
/*
* Should we check for enabled operations (/proc/sysrq-trigger
@@ -615,6 +658,15 @@ void __handle_sysrq(u8 key, bool check_mask)
}
} else {
pr_info("HELP : ");
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ /* Check if the crash op is actually in the table and is the crash_op. */
+ if (sysrq_key_table_key2index('c') != -1 &&
+ sysrq_key_table[sysrq_key_table_key2index('c')] == &sysrq_crash_op)
+ pr_cont("%s ", sysrq_crash_op.help_msg);
+ else /* Should not happen if table is defined correctly */
+ pr_cont("[Crash command not available] ");
+#else
+ int i;
/* Only print the help msg once per handler */
for (i = 0; i < ARRAY_SIZE(sysrq_key_table); i++) {
if (sysrq_key_table[i]) {
@@ -628,6 +680,7 @@ void __handle_sysrq(u8 key, bool check_mask)
pr_cont("%s ", sysrq_key_table[i]->help_msg);
}
}
+#endif
pr_cont("\n");
printk_force_console_exit();
}
@@ -1104,6 +1157,10 @@ static inline void sysrq_unregister_handler(void)
int sysrq_toggle_support(int enable_mask)
{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Runtime toggle is not allowed.\n");
+ return -EPERM;
+#else
bool was_enabled = sysrq_on();
sysrq_enabled = enable_mask;
@@ -1116,6 +1173,7 @@ int sysrq_toggle_support(int enable_mask)
}
return 0;
+#endif
}
EXPORT_SYMBOL_GPL(sysrq_toggle_support);
@@ -1145,12 +1203,30 @@ static int __sysrq_swap_key_ops(u8 key, const struct sysrq_key_op *insert_op_p,
int register_sysrq_key(u8 key, const struct sysrq_key_op *op_p)
{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ /*
+ * In CRASH_ONLY mode, do not allow registering new SysRq ops.
+ */
+ pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Cannot register new SysRq key '%c'.\n", key);
+ return -EPERM;
+#endif
return __sysrq_swap_key_ops(key, op_p, NULL);
}
EXPORT_SYMBOL(register_sysrq_key);
int unregister_sysrq_key(u8 key, const struct sysrq_key_op *op_p)
{
+#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
+ /*
+ * In CRASH_ONLY mode, do not allow unregistering the crash op.
+ * Other ops should be NULL anyway due to sysrq_init_crash_only_table.
+ */
+ if (op_p == &sysrq_crash_op) {
+ pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Cannot unregister the crash SysRq key '%c'.\n", key);
+ return -EPERM;
+ }
+ return -EPERM; /* Attempt to unregister anything else is also an error */
+#endif
return __sysrq_swap_key_ops(key, NULL, op_p);
}
EXPORT_SYMBOL(unregister_sysrq_key);
@@ -1209,6 +1285,7 @@ static inline void sysrq_init_procfs(void)
static int __init sysrq_init(void)
{
sysrq_init_procfs();
+ sysrq_init_crash_only_table();
if (sysrq_on())
sysrq_register_handler();
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ebe33181b6e6..c05b80cfb8aa 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -640,6 +640,19 @@ config MAGIC_SYSRQ_DEFAULT_ENABLE
This may be set to 1 or 0 to enable or disable them all, or
to a bitmask as described in Documentation/admin-guide/sysrq.rst.
+config MAGIC_SYSRQ_CRASH_ONLY
+ bool "Restrict Magic SysRq to crash command only"
+ depends on MAGIC_SYSRQ
+ default n
+ help
+ If you say Y here, the Magic SysRq key functionality will be
+ severely restricted at compile time. Only the 'c' command (trigger
+ a system crash) will be available. All other SysRq commands will be
+ disabled, and no new SysRq commands can be registered at runtime.
+ The /proc/sys/kernel/sysrq setting will be ineffective for
+ non-crash commands, and attempts to change it may be blocked.
+ This is a security hardening option.
+
config MAGIC_SYSRQ_SERIAL
bool "Enable magic SysRq key over serial"
depends on MAGIC_SYSRQ
--
2.33.0.windows.2
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
2025-06-07 15:19 [PATCH] tty: sysrq: Introduce compile-time crash-only mode Marwan Seliem
@ 2025-06-09 7:48 ` Jiri Slaby
2025-06-11 6:33 ` Marwan Seliem
1 sibling, 0 replies; 6+ messages in thread
From: Jiri Slaby @ 2025-06-09 7:48 UTC (permalink / raw)
To: Marwan Seliem, gregkh; +Cc: akpm, linux-kernel, linux-serial
On 07. 06. 25, 17:19, Marwan Seliem wrote:
> This commit introduces a new Kconfig option, CONFIG_MAGIC_SYSRQ_CRASH_ONLY,
> which allows for a significant hardening of the system by restricting
> the Magic SysRq functionality at compile time.
>
> Security Impact:
> - Reduces attack surface by disabling non-essential SysRq commands
> - Maintains critical crash-dump capability required for debugging
> - Eliminates runtime configuration vulnerabilities
>
> When CONFIG_MAGIC_SYSRQ_CRASH_ONLY is enabled:
>
> 1. Restricted Commands: Only the 'c' (trigger a system crash/dump)
> SysRq command remains operational. All other built-in SysRq commands
> (e.g., reboot, sync, show-memory, SAK) are disabled.
I must admit I don't much understand the purpose of this. It can be
spelled as: you can crash the system only by sysrq-c from now on. Don't
use sysrq-r or others. Who did ask for this?
...
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -584,7 +620,6 @@ void __handle_sysrq(u8 key, bool check_mask)
> {
> const struct sysrq_key_op *op_p;
> int orig_suppress_printk;
> - int i;
>
> orig_suppress_printk = suppress_printk;
> suppress_printk = 0;
> @@ -599,7 +634,15 @@ void __handle_sysrq(u8 key, bool check_mask)
> */
> printk_force_console_enter();
>
> +#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
> + if (key != 'c') { /* In CRASH_ONLY mode, only 'c' is considered */
> + op_p = NULL;
> + } else {
> + op_p = __sysrq_get_key_op(key);
> + }
> +#else
> op_p = __sysrq_get_key_op(key);
> +#endif
These inline #ifdefs are horrid.
> if (op_p) {
> /*
> * Should we check for enabled operations (/proc/sysrq-trigger
...
> @@ -1104,6 +1157,10 @@ static inline void sysrq_unregister_handler(void)
>
> int sysrq_toggle_support(int enable_mask)
> {
> +#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
> + pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Runtime toggle is not allowed.\n");
This can be invoked from userspace. So you can nicely DoS the machine by
the added warn, right? Hint: use ratelimiting.
> + return -EPERM;
> +#else
> bool was_enabled = sysrq_on();
>
> sysrq_enabled = enable_mask;
...
> @@ -1145,12 +1203,30 @@ static int __sysrq_swap_key_ops(u8 key, const struct sysrq_key_op *insert_op_p,
>
> int register_sysrq_key(u8 key, const struct sysrq_key_op *op_p)
> {
> +#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
> + /*
> + * In CRASH_ONLY mode, do not allow registering new SysRq ops.
> + */
> + pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Cannot register new SysRq key '%c'.\n", key);
> + return -EPERM;
> +#endif
> return __sysrq_swap_key_ops(key, op_p, NULL);
> }
> EXPORT_SYMBOL(register_sysrq_key);
>
> int unregister_sysrq_key(u8 key, const struct sysrq_key_op *op_p)
> {
> +#ifdef CONFIG_MAGIC_SYSRQ_CRASH_ONLY
> + /*
> + * In CRASH_ONLY mode, do not allow unregistering the crash op.
> + * Other ops should be NULL anyway due to sysrq_init_crash_only_table.
> + */
> + if (op_p == &sysrq_crash_op) {
> + pr_warn("SysRq: CONFIG_MAGIC_SYSRQ_CRASH_ONLY is set. Cannot unregister the crash SysRq key '%c'.\n", key);
> + return -EPERM;
No need for this return ^^.
> + }
> + return -EPERM; /* Attempt to unregister anything else is also an error */
> +#endif
> return __sysrq_swap_key_ops(key, NULL, op_p);
> }
> EXPORT_SYMBOL(unregister_sysrq_key);
> @@ -1209,6 +1285,7 @@ static inline void sysrq_init_procfs(void)
> static int __init sysrq_init(void)
> {
> sysrq_init_procfs();
> + sysrq_init_crash_only_table();
>
> if (sysrq_on())
> sysrq_register_handler();
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index ebe33181b6e6..c05b80cfb8aa 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -640,6 +640,19 @@ config MAGIC_SYSRQ_DEFAULT_ENABLE
> This may be set to 1 or 0 to enable or disable them all, or
> to a bitmask as described in Documentation/admin-guide/sysrq.rst.
>
> +config MAGIC_SYSRQ_CRASH_ONLY
> + bool "Restrict Magic SysRq to crash command only"
> + depends on MAGIC_SYSRQ
> + default n
> + help
> + If you say Y here, the Magic SysRq key functionality will be
> + severely restricted at compile time. Only the 'c' command (trigger
> + a system crash) will be available. All other SysRq commands will be
> + disabled, and no new SysRq commands can be registered at runtime.
> + The /proc/sys/kernel/sysrq setting will be ineffective for
> + non-crash commands, and attempts to change it may be blocked.
> + This is a security hardening option.
Is it for real?
thanks,
--
js
suse labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
2025-06-07 15:19 [PATCH] tty: sysrq: Introduce compile-time crash-only mode Marwan Seliem
2025-06-09 7:48 ` Jiri Slaby
@ 2025-06-11 6:33 ` Marwan Seliem
2025-06-19 11:20 ` Greg KH
1 sibling, 1 reply; 6+ messages in thread
From: Marwan Seliem @ 2025-06-11 6:33 UTC (permalink / raw)
To: jirislaby; +Cc: gregkh, akpm, linux-kernel, linux-serial
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 2417 bytes --]
Hi Jiri,
Thank you for your review and feedback. Let me address your comments and provide more context about the use case for this change.
> I must admit I don't much understand the purpose of this. It can be
> spelled as: you can crash the system only by sysrq-c from now on. Don't
> use sysrq-r or others. Who did ask for this?
This change was created with embedded systems that have external subsystems in mind (like modems/co-processors) where we need:
- The ability to trigger a full system crash (via sysrq-c) to collect subsystem crash dumps
- While explicitly disabling all other sysrq functionality for security reasons
In these environments:
- Crash dumps are essential for debugging
- Other sysrq commands pose unnecessary security risks
> These inline #ifdefs are horrid.
Agreed. I will restructure this.
> This can be invoked from userspace. So you can nicely DoS the machine by
> the added warn, right? Hint: use ratelimiting.
Good point. I'll add ratelimiting to the pr_warn() calls or we can consider reducing these to pr_debug()?
> No need for this return ^^.
You're right, the second return is redundant. I'll clean this up.
> Is it for real?
From a pure security viewpoint, expert advice is to remove this Magic Sysrq functionality,
either with kernel.sysrq=0 in sysctl config file, or with a full kernel rebuild
with n value for CONFIG_MAGIC_SYSRQ parameter.
This patch provides a middle ground that:
1) Resolves the Core Security Conflict
The CRASH_ONLY mode provides the minimal debug capability while eliminating:
- Register dumps (disables 'p' command)
- Filesystem operations (disables 'u'/sync commands)
- All other privileged operations
2) Security Architecture Benefits
Traditional: All-or-nothing
│─────────────┬─────────────│
Full disable Full enable
Our Approach: Principle of Least Privilege
│─────┬───────┬─────────────│
Off Crash-only Full enable
For v2 of the patch, I'll make these improvements:
1) Restructure to minimize #ifdef fiasco
2) Add proper rate limiting on pr_warn/change it to pr_debug
3) Clean up redundant return
Thank you again for your valuable feedback. I appreciate you taking the time to review this.
Warmest regards,
Marwan Seliem
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
2025-06-11 6:33 ` Marwan Seliem
@ 2025-06-19 11:20 ` Greg KH
2025-07-07 21:16 ` Marwan Seliem
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2025-06-19 11:20 UTC (permalink / raw)
To: Marwan Seliem; +Cc: jirislaby, akpm, linux-kernel, linux-serial
On Wed, Jun 11, 2025 at 09:33:49AM +0300, Marwan Seliem wrote:
> Hi Jiri,
>
> Thank you for your review and feedback. Let me address your comments and provide more context about the use case for this change.
>
> > I must admit I don't much understand the purpose of this. It can be
> > spelled as: you can crash the system only by sysrq-c from now on. Don't
> > use sysrq-r or others. Who did ask for this?
>
> This change was created with embedded systems that have external subsystems in mind (like modems/co-processors) where we need:
> - The ability to trigger a full system crash (via sysrq-c) to collect subsystem crash dumps
> - While explicitly disabling all other sysrq functionality for security reasons
"security" involves crashing the system, so I fail to understand why one
is more "secure" than the other.
Sorry, someone needs to go back and talk to the people who think that
this is going to result in a more secure system as that's just not the
case at all.
> In these environments:
> - Crash dumps are essential for debugging
> - Other sysrq commands pose unnecessary security risks
Again, I don't buy it, sorry.
> > Is it for real?
>
> >From a pure security viewpoint, expert advice is to remove this Magic Sysrq functionality,
> either with kernel.sysrq=0 in sysctl config file, or with a full kernel rebuild
> with n value for CONFIG_MAGIC_SYSRQ parameter.
> This patch provides a middle ground that:
> 1) Resolves the Core Security Conflict
> The CRASH_ONLY mode provides the minimal debug capability while eliminating:
> - Register dumps (disables 'p' command)
> - Filesystem operations (disables 'u'/sync commands)
> - All other privileged operations
> 2) Security Architecture Benefits
>
> Traditional: All-or-nothing
> │─────────────┬─────────────│
> Full disable Full enable
>
> Our Approach: Principle of Least Privilege
> │─────┬───────┬─────────────│
> Off Crash-only Full enable
I don't understand your graphs here, what are you trying to say?
Somehow still allowing someone to crash the system still is "secure"?
confused,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
2025-06-19 11:20 ` Greg KH
@ 2025-07-07 21:16 ` Marwan Seliem
2025-07-08 8:05 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Marwan Seliem @ 2025-07-07 21:16 UTC (permalink / raw)
To: gregkh; +Cc: akpm, jirislaby, linux-kernel, linux-serial, marwanmhks
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
2025-07-07 21:16 ` Marwan Seliem
@ 2025-07-08 8:05 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2025-07-08 8:05 UTC (permalink / raw)
To: Marwan Seliem; +Cc: akpm, jirislaby, linux-kernel, linux-serial
On Tue, Jul 08, 2025 at 12:16:50AM +0300, Marwan Seliem wrote:
> 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
One can make this argument for each of the sysrq options, but attempting
to make each one a config option is crazy. We have chosen the "either
all or none" to make things simpler overall.
So attempting to maintain yet-another-configuration-option like this,
for the next 40+ years, is adding to our maintance burden for almost no
benifit that I can determine (hint, I still think it's crazy to allow a
system to crash but not the other things.)
So I can't accept this added complexity at this point in time, sorry.
If you can convince others that this really is worth the overhead
involved in it, please do so and come back with some more support.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-07-08 8:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-07 15:19 [PATCH] tty: sysrq: Introduce compile-time crash-only mode Marwan Seliem
2025-06-09 7:48 ` Jiri Slaby
2025-06-11 6:33 ` Marwan Seliem
2025-06-19 11:20 ` Greg KH
2025-07-07 21:16 ` Marwan Seliem
2025-07-08 8:05 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).