From: Greg KH <gregkh@linuxfoundation.org>
To: Marwan Seliem <marwanmhks@gmail.com>
Cc: jirislaby@kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH] tty: sysrq: Introduce compile-time crash-only mode
Date: Thu, 19 Jun 2025 13:20:58 +0200 [thread overview]
Message-ID: <2025061938-making-igloo-3326@gregkh> (raw)
In-Reply-To: <20250611063349.25187-1-marwanmhks@gmail.com>
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
next prev parent reply other threads:[~2025-06-19 11:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2025-07-07 21:16 ` Marwan Seliem
2025-07-08 8:05 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2025061938-making-igloo-3326@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=marwanmhks@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).