Workflows Archive on
 help / color / Atom feed
From: Steven Rostedt <>
To: Evan Rudford <>
Subject: Re: Is the Linux kernel underfunded? Lack of quality and security?
Date: Wed, 18 Nov 2020 14:51:27 -0500
Message-ID: <20201118145127.16ecb072@gandalf.local.home> (raw)
In-Reply-To: <>

On Wed, 18 Nov 2020 20:30:48 +0100
Evan Rudford <> wrote:

> Am Mi., 18. Nov. 2020 um 19:13 Uhr schrieb Steven Rostedt <>:
> >
> > On Wed, 18 Nov 2020 18:59:09 +0100
> > Evan Rudford <> wrote:
> >  
> > > This is perhaps hard to argue because the competition isn't good.
> > > To be honest, I feel that neither Linux nor any other "major" OS is
> > > reaching "high" security-standards.
> > > It is a fallacy to think that the security-situation is good just
> > > because nobody else is better.
> > > And of course, rewriting Linux is nearly impossible, but I doubt that
> > > Linux will ever become "truly secure" as long as everything is written
> > > in C.
> > > Let's face the reality: C is an excellent systems programming
> > > language, but it is like an "unprotected chainsaw" with respect to
> > > security.
> > >  
> >
> > I call "bull" on the above statement. This C isn't secure, is just a
> > blanket statement. Yes, C has issues, and so does assembly (which there's
> > plenty of that in the kernel). But with the amount of static analyzers and
> > fuzz testing going on, the typical C bugs that are in most projects are
> > well discovered in the Linux kernel.  
> I fully agree that Linux uses many fuzzers/analyzers that are not
> typically used by a lot of C-projects.
> However, to claim that C is still "good practice" would be an insult
> against all the research on memory safety vulnerabilities over the
> last decades.
> We should not trash all this research just because many programmers
> are more convenient with C.
> In other words, I argue that we should avoid a hostile environment
> where new research-results are destroyed just because some people
> think that this is "not practical".
> Rust and other languages were not only invented as fun side projects,
> but because the knowledge of today is way better than the knowledge
> back in the 1990s when Linux wrote the initial kernel.

I'm a fan of Rust. And I'm all for moving to Rust for user space
applications, and perhaps even as Linux kernel modules (there's work on
supporting this).

But the Linux kernel itself is driven to be close to optimal in
performance, and for tooling. We push C to its limit. The Linux kernel even
does a bit of dynamic code modifications at run time. It's not about
convenience, it's about systems programing and pushing the limits of how
powerful you can make your hardware run.

There's a lot that Linux does that is out of scope of normal user space,
and the kernel is also limited in what it does as well (it has a limited
stack, and needs to take extra care not to overflow it). It limits options
of the compiler because it expects the compiler to be deterministic where
optimizations can break some of the tricks that the kernel performs.

I like to think of Linux as the German autobahn and everything else like US
highways. Linux has no speed limit, but is very strict on the rules (must
stay in the right lane, and only pass on the left, etc). When things go
wrong, there can be huge consequences. Everything else is like the US
highway. More lenient on the rules, but have to have speed limits. Things
can still go badly, but not as bad as when you are going over 100 mph (160

> > > > Again, citation please?  I would argue that right now we have too many
> > > > people/resources working on security issues that are really really minor
> > > > in the overall scheme of things.
> > > > greg k-h  
> > >
> > > I agree that the current security-efforts might not be well-directed
> > > for the overall scheme of things.
> > > However, I don't think that security has "too many" people in total.
> > > It might be true that "minor" security-issues are eating too many
> > > resources, but there are still "non-minor" security issues that are
> > > not yet addressed.  
> >
> > Funny, I find that the biggest threat to security today is coming from the
> > hardware. Issues like spectre and meltdown, and everything to do with
> > parallel programming is going to be the new age of cracking the system. And
> > ironically, C and assembly are probably the best languages to counter it ;-)
> >
> > -- Steve  
> I believe that Spectre and Meltdown are kind of orthogonal to many
> other security threats.
> Yes, I fully agree that Spectre and Meltdown need to be addressed, but
> I still consider arbitrary buffer overflows in parsing libraries as
> more dangerous than "typical" Spectre/Meltdown threats.

I expect that there will be a lot more vulnerable attacks in user space
than what you'll find in the kernel. Rust can help with that. If user space
is written more in Rust and we even have more Rust Linux modules, perhaps
things can get better. But there's no interest in rewriting the Linux core
code in any other language if that's what you are getting at.

-- Steve

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-05  3:49 Evan Rudford
2020-01-05  8:15 ` Greg KH
2020-11-18 17:59   ` Evan Rudford
2020-11-18 18:13     ` Steven Rostedt
2020-11-18 19:30       ` Evan Rudford
2020-11-18 19:51         ` Steven Rostedt [this message]
2020-11-18 19:53         ` Theodore Y. Ts'o

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201118145127.16ecb072@gandalf.local.home \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Workflows Archive on

Archives are clonable:
	git clone --mirror workflows/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 workflows workflows/ \
	public-inbox-index workflows

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone