6 ms·

> 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 bu

> 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'm not sure if the majority of CVEs for the Linux kernel come down to memory safety, though I would not be surprised, but certainly a huge number are. > without a clear and obvious benefit beyond promises that can only truly be fully fulfilled with a whole kernel written in Rust. That's not true, really. You don't need a completely safe kernel to have an improvement to safety. If every device driver were memory safe tomorrow we'd be better off. That said, I think this will be an interesting, possibly losing, battle. The Linux Kernel is extremely monolithic, it has a lack of testing and code review, decades of dug-in investments, and a strong history of not prioritizing security or even considering it to be a legitimate goal. Fixing that seems like it will itself take decades, whereas the current approach really feels like it's trying to get it done ASAP. If they can do it, cool. As a Linux user I'll possibly benefit. I'm curious to see how it plays out.

CraigJPerry 5y ago
>> 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?
- medstrom 5y ago
  I don't think it lacks code review, it's famously hard to get half-baked stuff through Torvalds.
  - staticassertion 5y ago
    That isn't really true.
  - wott 5y ago
    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.
  - Mic92 5y ago
    They don't even do CI when reviewing patches. Some of the code they review on mailing lists does not even compile.
  - yissp 5y ago
    The recent UMN controversy would seem to disprove this.
- rocqua 5y ago
  On testing, linux does not come with a suite of regression tests.
  - cesarb 5y ago
    > linux does not come with a suite of regression tests https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing?h=v5.13 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- geofft 5y ago
  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-local-privilege-escalation-linux.txt 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?
  - bowyakka 5y ago
    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?
- staticassertion 5y ago
  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.
wiz21c 5y ago
I tend to see Linux with rosy glasses, so : > a strong history of not prioritizing security or even considering it is that really true ?
- sennight 5y ago
  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.
- freedomben 5y ago
  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.
  - staticassertion 5y ago
    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.
quietbritishjim 5y ago
> > 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.
medstrom 5y ago
With all its build options and modules, the traditional monolith-microkernel distinction doesn't really apply. Do you mean something else by "extremely monolithic"?
- akiselev 5y ago
  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.
_wldu 5y ago
I believe the author meant "logic mistakes". I agree the current wording is confusing.
- staticassertion 5y ago
  I agree, though I wondered if that was actually true - I don't think so? But I don't know.
  - est31 5y ago
    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.
    - ncmncm 5y ago
      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.
      - kobebrookskC3 5y ago
        for another operating system, we have ~70% of security bugs being memory safety issues (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...). sounds like a decent majority to me.
jcranmer 5y ago
> 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.
- ungamedplayer 5y ago
  Also, spectre meltdown, all the hw cves, there are a bunch of bluetooth protocol flaws.. the list goes on.
paulddraper 5y ago
> 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.
- alexjplant 5y ago
  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 https://lkml.org/lkml/2008/7/15/296
  - paulddraper 5y ago
    Wow, excellent stuff. > To me, security is important. But it's no less important than everything else that is also important! > - Linus
    - trulyme 5y ago
      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).
      - akiselev 5y ago
        > Linus could learn some manners He acknowledged that and did so, years ago.
        trulyme 5y 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.
        5y ago
paulddraper 5y ago
> What CVEs aren't due to programming mistakes? Spectre
- xxpor 5y ago
  Is writing verilog/vhdl programming?
  - pjmlp 5y ago
    Looks like C and Ada dialects to me.
  - paulddraper 5y ago
    Yes, but I think the problem is more due to physics.
- woodruffw 5y ago
  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.
  - cesarb 5y ago
    > 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.
mrtweetyhack 5y ago
CVE-2021-36934 MS SAM file can be read by anyone

CraigJPerry 5y ago

>> 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?

medstrom 5y ago
I don't think it lacks code review, it's famously hard to get half-baked stuff through Torvalds.
- staticassertion 5y ago
  That isn't really true.
- wott 5y ago
  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.
- Mic92 5y ago
  They don't even do CI when reviewing patches. Some of the code they review on mailing lists does not even compile.
- yissp 5y ago
  The recent UMN controversy would seem to disprove this.
rocqua 5y ago
On testing, linux does not come with a suite of regression tests.
- cesarb 5y ago
  > linux does not come with a suite of regression tests https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing?h=v5.13 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
geofft 5y ago
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-local-privilege-escalation-linux.txt 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?
- bowyakka 5y ago
  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?
staticassertion 5y ago
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.

wiz21c 5y ago

I tend to see Linux with rosy glasses, so : > a strong history of not prioritizing security or even considering it is that really true ?

sennight 5y ago
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.
freedomben 5y ago
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.
- staticassertion 5y ago
  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.

quietbritishjim 5y ago

> > 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.

medstrom 5y ago

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

akiselev 5y ago
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.

_wldu 5y ago

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

staticassertion 5y ago
I agree, though I wondered if that was actually true - I don't think so? But I don't know.
- est31 5y ago
  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.
  - ncmncm 5y ago
    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.
    - kobebrookskC3 5y ago
      for another operating system, we have ~70% of security bugs being memory safety issues (https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...). sounds like a decent majority to me.

jcranmer 5y ago

> 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.

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

paulddraper 5y ago

> 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.

alexjplant 5y ago
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 https://lkml.org/lkml/2008/7/15/296
- paulddraper 5y ago
  Wow, excellent stuff. > To me, security is important. But it's no less important than everything else that is also important! > - Linus
  - trulyme 5y ago
    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).
    - akiselev 5y ago
      > Linus could learn some manners He acknowledged that and did so, years ago.
      - trulyme 5y 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.
        5y ago

paulddraper 5y ago

> What CVEs aren't due to programming mistakes? Spectre

xxpor 5y ago
Is writing verilog/vhdl programming?
- pjmlp 5y ago
  Looks like C and Ada dialects to me.
- paulddraper 5y ago
  Yes, but I think the problem is more due to physics.
woodruffw 5y ago
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.
- cesarb 5y ago
  > 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.

mrtweetyhack 5y ago

CVE-2021-36934 MS SAM file can be read by anyone