Hacker News Reader

I believe the author meant "logic mistakes". I agree the current wording is confusing.

I agree, though I wondered if that was actually true - I don't think so? But I don't know.

The question whether a logic bug can be turned into an exploit depends on the domain of the program. An image format decoder written in safe Rust might yield a pixel in a different color due to a logic bug, but that's the worst impact it can have. In software reasoning about security constraints however, a logic bug can mean the user now has root privileges, can write to /etc/shadow as an unprivileged user, or the TLS certificate is considered valid for the domain even though it isn't.

Rust's safety promises don't prevent logic bug CVEs in the kernel. But I think it would be a major improvement if the kernel were written in mostly safe Rust.

This is not a matter of opinion. The collection of CVEs reported (which represent an unknown fraction of faults that could in principle be found) clearly identify which are memory usage bugs of a type that could be prevented by a compiler. My reading is that the large majority are not.

If the demonstrated complacency of Rust coders toward potential bugs is factored in, and inexperience with the language among potential reviewers, use of Rust in the kernel could actually increase the number of exploitable faults. I do not assert this would certainly occur, but no one can demonstrate it would not.

> If the demonstrated complacency of Rust coders toward potential bugs

lol what?

This is so very the opposite of my 6+ years of experience in Rust, where the community has a serious focus on testing, and great tooling support for it as well.

I honestly can't take anyone seriously who thinks that adding Rust to the kernel will increase security bugs. I just can't imagine they know anything about Rust, security, or the kernel.

I judge based on the tide of opinion that washes up, everywhere Rust is even mentioned, that bugs in Rust code are physically impossible. That is the whole value proposition of the language, as presented. Anyone hinting that bugs are still possible in Rust gets downvoted to oblivion (as here).

I do not doubt that there are Rust coders who are especially vigilant about introducing bugs, but they certainly are, as in all times and places, the exception.

> that bugs in Rust code are physically impossible

This isn't a real thing either. I see it asserted all the time on HN and it's hilarious.

> Anyone hinting that bugs are still possible in Rust gets downvoted to oblivion (as here).

90% of the time it's because the person is making a stupid point. 10% of the time it's the community being annoying.

So just to reiterate, you're basing this on being barely an observer on forums, and I'm basing this on multiple years of professional rust development.

for another operating system, we have ~70% of security bugs being memory safety issues (https://www.zdnet.com/article/microsoft-70-percent-of-all-se...). sounds like a decent majority to me.

There's a similar effect as Amdahl's law with these. Only after programmers come to their senses and opt to take care of that 70%, we get to the remaining part of the pie and its subdivisions, and can start thinking about the actually interesting part of engineering secure systems.

The overwhelming prevalence and impact of memory safety bugs has retared development of solutions for the remaining, nontrivial problems for many decades, by consuming so much of the attention.

Windows is Windows, and Microsoft is Microsoft. Extrapolation from those to anywhere else in the universe does not generate a plausible argument.

how about

https://www.chromium.org/Home/chromium-security/memory-safet...

https://langui.sh/2019/07/23/apple-memory-safety/

these companies apply things like sandboxing and fuzzing to reduce the incidence of memory unsafety bugs, and yet they're finding a majority of their security bugs being memory unsafety. if you can't find memory unsafety in your c++ code, it's because your code isn't worth attacking.

These, also, are not Linux. If in fact Linux CVEs matched such a pattern, somebody would be certain to be jumping up and down pointing it out.

hey, whaddya know, i just stumbled upon this today https://twitter.com/geofft/status/1132739184060489729

YeahI get all of that fwiw I would consider design issues programming errors but it doesn't really matter.

> What CVEs aren't due to programming mistakes?

Shellshock would be a good candidate: Bash is designed to be able to pass around some amount of shell scripting in environment variables, which obviously leads to some pretty severe security issues if attackers can control environment variables (say, CGI scripts). So you can argue that the problem here is a design mistake rather than a programming mistake.

Also, spectre meltdown, all the hw cves, there are a bunch of bluetooth protocol flaws.. the list goes on.

> > Since most of our CVE type problems are usually programming mistakes nowadays, the lack of review could contribute to an increase in programming fault type bugs which aren't forbidden by the safer memory model.

> That's an odd statement. What CVEs aren't due to programming mistakes?

I guess they meant as opposed to higher level design mistakes.

>> it has a lack of testing and code review

Is that really true? I mean my first reaction is that the linked article / thread is a direct counterpoint. All the review and testing the rust facilities are going through.

Are these changes not going through substantively the same process as other proposed changes to the kernel?

The fact that a process is burdensome does not mean it is necessarily effective.

Look at the seq_file thing Qualys discovered the other day. The overflow was obvious if you thought about it, and all Qualys did was think about it. But the bug was present since 2014.

https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-loc...

Linus's law is empirically untrue for security bugs - many eyes don't actually spot them. Moreover, we have computers, which are good at doing repetitive and detail-oriented tasks with 100% accuracy. Why not use them?

Hmmm while I agree with you, doesn't the fact qualsys went looking out eyes on it? We sure that a seq_lock bug isn't present in say OSX, QNX, Windows?

No, what we have here is definitely more of an exception - sort of like an RFC for larger changes that could take months or years to play out. The vast majority of code changes do not go through this.

On testing, linux does not come with a suite of regression tests.

> linux does not come with a suite of regression tests

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

I don't think it lacks code review, it's famously hard to get half-baked stuff through Torvalds.

The ton of driver code that piles up in the Linux kernel every minute doesn't go through Torvalds. It is delegated.

And my reviewing of a few drivers source short commits is enough to tell me that those delegates do not perform a satisfyingly thorough review by any mean.

Heck, I saw patches of just a couple dozen lines which exhibited bad copy-pasting errors anyone without prior knowledge could have spotted. You don't need to know what the code does to spot some, you don't either need to know what the driven device does to spot some: purely formal errors with bad macros definitions for example. This kind of stuff wouldn't even pass the first internal review where I worked, which just looked at formal appearance (then there were more in depth reviews, and then there was an external review, but we'd make as sure as possible that our code would be clean before going out).

So first you have people (employees of company A) which sends code to a public, external project without having done a proper internal review. Then you have someone else (employee from company B) who claims to have reviewed the commit but hasn't done it properly or at all. And then possibly a third someone who validates this, but doesn't actually check either. It has become a job, a task like another, with the same people who do the same sloppy job as quickly as possible to get rid of it and go home earlier or slack, in the same proportion that you can find in any other position in the world.

They don't even do CI when reviewing patches. Some of the code they review on mailing lists does not even compile.

That isn't really true.

The recent UMN controversy would seem to disprove this.

I tend to see Linux with rosy glasses, so :

> a strong history of not prioritizing security or even considering it

is that really true ?

No. Security is important and definitely considered.

Some years back there was a viral blow-up where Linus basically said, "security is important but there are lots of things that are important." A lot of people in the security field decided that meant "not even considered" even though that's ridiculous. Linus has always had a pragmatic, holistic approach to the kernel, and many specialists hate that because they think their field is the most important and all others should be second.

If security wasn't even considered, would Linux really have become the de-facto base on which high security orgs (banks, 3 letter gov agencies, etc) deploy? I doubt it very much.

As a security engineer who has seen egregious security malpractice on the part of developers, I fully agree that there can be a real problem with that. However I think it's silly to suggest that the Linux kernel has a history of not even considering security.

You've built a straw-man for my statement and you've completely mischaracterized Linus.

Linus had multiple statements that won him pwnies, but what I'm referring to is decades of mailing list posts where he's insulted researchers, or decades of him and Greg rejecting CVEs and hiding vulnerabilities, etc. This has persisted even today, mostly from Greg, but in a less public way than it once was due to cultural shifts.

Make no mistake, Linus and Greg have always had a hostile relationship with security researchers.

> many specialists hate that because they think their field is the most important and all others should be second.

Another straw man. I never said anything like this; that security should be the number one priority or that anything else shouldn't be a priority.

> would Linux really have become the de-facto base on which high security orgs (banks, 3 letter gov agencies, etc) deploy? I doubt it very much.

Is this satire? Are we really going with "Banks deploy Linux... therefor it's secure" ? Did you know banks also run Windows XP on their ATMs?

Linux has had external contributions to security, yes. Much of that has been despite upstream, and with immense work across decades to get upstream to play ball.

> However I think it's silly to suggest that the Linux kernel has a history of not even considering security.

Sorry but the only way for this to be the case is to simply not know the history of the Linux kernel.

Do a quick search of the terms: Linus Torvalds security. Pick any one of the results. While some of his points with regard to utility vs security seem to have merit... when you switch out "secure" with "correct" the problem becomes pretty obvious.

> What CVEs aren't due to programming mistakes?

Spectre

Is writing verilog/vhdl programming?

Yes, but I think the problem is more due to physics.

Looks like C and Ada dialects to me.

I think there's a strong argument to be made for Spectre being a programming mistake, with the programming in question being Intel and AMD's proprietary microcode formats. We'd consider a similar timing/information channel in C to be a programming mistake, so it's not clear why we should exclude one in a lower-level representation.

> with the programming in question being Intel and AMD's proprietary microcode formats

No, as far as I know, the design mistakes which lead to Spectre (and other similar vulnerabilities) are not on the microcode; these design mistakes are on an even lower level, in the hardware structures which execute both simple instructions (which are decoded directly, without going through the microcode engine) and microcode instructions. Most of what the microcode "fixes" for Spectre and similar do, is flipping a few "chicken bits" (to disable or bypass some of the hardware structures), and providing extra semantics to a few of the complex instructions (which go through the microcode engine) like LFENCE and VERW; these changes do not actually fix the problem (which is on physical hardware), but instead give software ways to workaround the issue.

You should argue instead that the programming in question is the VHDL or Verilog (or other proprietary language) which was used to generate the hardware.

And, in any case those are also not coding bugs either, but architectural design bugs. Any hypothetical smarter, more suspicious HDL would have been wholly unable to prevent them, because the hardware is working exactly as designed and specified. The designers actually knew all about the flaws, they just thought they didn't matter.

With all its build options and modules, the traditional monolith-microkernel distinction doesn't really apply. Do you mean something else by "extremely monolithic"?

It's not so much the Linux kernel that's monolithic, but the Linux source code. Since drivers gets mainlined, they become part of the Linux stability guarantee. When a significant fraction of the source code is drivers for specialized devices (i.e. AMD GPUs), the development process takes on the characteristics of an extreme monolith that requires coordination of many different teams.

> a strong history of not prioritizing security or even considering it to be a legitimate goal

?

Did you mean the Windows kernel?

Linux has had incredible focus on security. SELinux being a prime example.

No, Windows has by far more investment into security and a far better culture. Linux has a multiple-decades-long history of saying that security is not important and has had to be dragged kicking and screaming to modernity.

SELinux is just an LSM built decades ago, I wouldn't say that somehow proves that upstream cares about security.

Probably a mischaracterization of Linux on the basis of Linus's infamous comment on OpenBSD devs [1].

[1] https://lkml.org/lkml/2008/7/15/296

Wow, excellent stuff.

> To me, security is important. But it's no less important than everything else that is also important!

> - Linus

With all due respect, Linus could learn some manners:

> I think the OpenBSD crowd is a bunch of...

Apart from that, if there is no test coverage it is difficult to talk about security or reliability (I don't know myself if there are tests and how good they are, I'm just assuming GGGP is right).

> Linus could learn some manners

He acknowledged that and did so, years ago.

I assume this was after the linked post then, and it's good to hear that. The problem is that these posts stay online for a loooong time. Thanks for answering.

The linked post was literally from 2008

> With all due respect, Linus could learn some manners

He himself wouldn't disagree with that.

Actually, not really, one has to look for Android, if wanting a Linux kernel with all the proper security knobs actually turned on and configured appropriately.

In an OS where Linux kernel is actually an implementation detail in what concerns userspace.