Hi Shuah,
On Fri, May 08, 2026 at 02:52:13PM -0600, Shuah Khan wrote:
> > +What qualifies as a security bug
> > +--------------------------------
> > +
> > +It is important that most bugs are handled publicly so as to involve the
> > widest
> > +possible audience and find the best solution. By nature, bugs that are
> > handled
> > +in closed discussions between a small set of participants are less likely
> > to
> > +produce the best possible fix (e.g., risk of missing valid use cases,
> > limited
> > +testing abilities).
> > +
> > +It turns out that the majority of the bugs reported via the security team
> > are
> > +just regular bugs that have been improperly qualified as security bugs due
> > to
> > +ignorance or misunderstanding of the Linux kernel's threat model described
> > in
>
> "lack of understanding" instead of ignorance?
I already had "misunderstanding", here I wanted to express the idea that
people could simply ignore that this file exists (since it's new). Do you
think we shouldn't care about this and just keep "misunderstanding" ?
(...)
> > +The Linux Kernel threat model
> > +=============================
> > +
> > +There are a lot of assumptions regarding what the kernel protects against
> > and
> > +what it does not protect against. These assumptions tend to cause
> > confusion for
>
> Could simply say "what it does not" or "what the kernel does and does not
> protect
> against"
Ah OK good point, I'll rephrase it.
> > +* **Configuration**:
> > +
> > + * outdated kernels and particularly end-of-life branches are out of the
> > scope
> > + of the kernel's threat model: administrators are responsible for
> > keeping
> > + their system up to date. For a bug to qualify as a security bug, it
> > must be
> > + demonstrated that it affects actively maintained versions.
> > +
> > + * build-level: changes to the kernel configuration that are explicitly
> > + documented as lowering the security level (e.g. ``CONFIG_NOMMU``), or
> > + targeted at developers only.
> > +
> > + * OS-level: changes to command line parameters, sysctls, filesystem
> > + permissions, user capabilities, exposure of privileged interfaces, that
> > + explicitly increase exposure by either offering non-default access to
> > + unprivileged users, or reduce the kernel's ability to enforce some
> > + protections or mitigations. Example: write access to procfs or debugfs.
> > +
> > + * issues triggered only when using features intended for development or
> > + debugging (e.g., lockdep, KASAN, fault-injection): these features are
> > known
> > + to introduce overhead and potential instability and are not intended
> > for
> > + production use.
>
> Can we call out features and tools (the ones in kernel repo)
Sure!
> sched_ext's Kconfig enables
> a few debug options including LOCKDEP
>
> tools/sched_ext/Kconfig:CONFIG_DEBUG_LOCKDEP=y
It's still there but maybe not visible enough, I should probably write
it in upper case:
debugging (e.g., lockdep, KASAN, fault-injection):
> > +* **Excess of initial privileges**:
> > +
> > + * actions performed by a user already possessing the privileges required
> > to
> > + perform that action or modify that state (e.g. ``CAP_SYS_ADMIN``,
> > + ``CAP_NET_ADMIN``, ``CAP_SYS_RAWIO``, ``CAP_SYS_MODULE`` with no
> > further
> > + boundary being crossed).
> > +
> > + * actions performed in user namespace without permitting anything in the
> > + initial namespace that was not already permitted to the same user
> > there.
>
> This was a bit hard to parse - examples might help here
Yeah when rereading it now, I fully agree. I think I should avoid the
double negation here and use a form such as;
* actions performed in user namespace that do not bypass the restrictions
imposed to the initial user.
If examples are still needed, I could possibly add: "(e.g. ptrace, signals,
FS or device access, system/network configuration, network binding)".
> > + * anything performed by the root user in the initial namespace (e.g.
> > kernel
> > + oops when writing to a privileged device).
> > +
> > +* **Out of production use**:
> > +
> > + This covers theoretical/probabilistic attacks that rely on laboratory
> > + conditions with zero system noise, or those requiring an unrealistic
> > number
> > + of attempts (e.g., billions of trials) that would be detected by standard
> > + system monitoring long before success, such as:
> > +
> > + * prediction of random numbers that only works in a totally silent
> > + environment (such as IP ID, TCP ports or sequence numbers that can
> > only be
> > + guessed in a lab).
> > +
> > + * activity observation and information leaks based on probabilistic
> > + approaches that are prone to measurement noise and not realistically
> > + reproducible on a production system.
> > +
> > + * issues that can only be triggered by heavy attacks (e.g. brute force)
> > whose
> > + impact on the system makes it unlikely or impossible to remain
> > undetected
> > + before they succeed (e.g. consuming all memory before succeeding).
> > +
> > + * problems seen only under development simulators, emulators, or
> > combinations
> > + that do not exist on real systems at the time of reporting (issues
> > + involving tens of millions of threads, tens of thousands of CPUs,
> > + unrealistic CPU frequencies, RAM sizes or disk capacities, network
> > speeds.
> > +
> > + * issues whose reproduction requires hardware modification or emulation,
> > + including fake USB devices that pretend to be another one.
> > +
> > + * as well as issues that can be triggered at a cost that is orders of
> > + magnitude higher than the expected benefits (e.g. fully functional
> > keyboard
> > + emulator only to retrieve 7 uninitialized bytes in a structure, or
> > + brute-force method involving millions of connection attempts to guess a
> > + port number).
>
> Can we add a section about problems found using experimental or tools
> in development stage?
You mean one more paragraph about CONFIG_EXPERIMENTAL ? Or what else do
you have in mind ? Do not hesiate to propose a paragraph if you have
anything in mind!
(...)
> Reviewed-by: Shuah Khan <[email protected]>
>
> thanks,
Thank you!
Willy
