3 ms·

Luckily this is JUST a local exploit but yet again shows that C should just die as a language.

by dtx1 3y ago

jug6ernaut 3y ago
> Luckily this is JUST a local exploit Its very rare for only one exploit to be used when a system is compromise. Multiple exploits will be used, one for entry, one for escalation of privileges, etc.
stefantalpalaru 3y ago
> yet again shows that C should just die as a language It's a logic error. Nothing to do with the language. "now that the vma layout uses the maple tree code, we *really* don't just change vm_start and vm_end any more, and the locking really is broken" - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9471f1f2f50282b9e8f59198ec6bb738b4ccc009 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
pengaru 3y ago
What about the commit message for the fix [0] makes you think this code, if it were written in say... rust, wouldn't have just been put in an unsafe block to do the "opportunistic" e.g. fast and dirty thing, anyways? When your development practices normalize cheating here and there for performance wins where it matters, any language capable of writing kernels isn't going to stop you. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9471f1f2f50282b9e8f59198ec6bb738b4ccc009 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- samus 3y ago
  The wording `unsafe` makes it very obvious that it is supposed to be a method of last resort. In C, it is very easy to accidentally drift into undefined behavior, and reviewers have to be aware of all the potential issues, which can occur everywhere. Rust's `unsafe` blocks at least make it obvious where exactly dangerous things are going on so refers can focus their attention there. And the Rust compiler still performs many checks inside `unsafe` blocks, most importantly borrow checking.
machina_ex_deus 3y ago
Rust hardly deals with memory race conditions better than C, and managed languages are not fit for kernel. This isn't the fault of C at all. These kinds of issues are unavoidable part of kernel programming in multiprocessor settings and not something you can solve with a different programming language. This comment just can't be more wrong.
- IshKebab 3y ago
  Rust deals with race conditions 100 times better than C. Have you tried it? Just because it can't guarantee that they never happen doesn't mean it isn't any better. You can't solve this with a different programming language but you can definitely make bugs much less likely.

Luckily this is JUST a local exploit but yet again shows that C should just die as a language.

by dtx1 3y ago

Luckily this is JUST a local exploit but yet again shows that C should just die as a language.

> Luckily this is JUST a local exploit Its very rare for only one exploit to be used when a system is compromise. Multiple exploits will be used, one for entry, one for escalation of privileges, etc.

stefantalpalaru 3y ago

> yet again shows that C should just die as a language It's a logic error. Nothing to do with the language. "now that the vma layout uses the maple tree code, we *really* don't just change vm_start and vm_end any more, and the locking really is broken" - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9471f1f2f50282b9e8f59198ec6bb738b4ccc009 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

pengaru 3y ago

What about the commit message for the fix [0] makes you think this code, if it were written in say... rust, wouldn't have just been put in an unsafe block to do the "opportunistic" e.g. fast and dirty thing, anyways? When your development practices normalize cheating here and there for performance wins where it matters, any language capable of writing kernels isn't going to stop you. [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9471f1f2f50282b9e8f59198ec6bb738b4ccc009 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

samus 3y ago
The wording `unsafe` makes it very obvious that it is supposed to be a method of last resort. In C, it is very easy to accidentally drift into undefined behavior, and reviewers have to be aware of all the potential issues, which can occur everywhere. Rust's `unsafe` blocks at least make it obvious where exactly dangerous things are going on so refers can focus their attention there. And the Rust compiler still performs many checks inside `unsafe` blocks, most importantly borrow checking.

machina_ex_deus 3y ago

Rust hardly deals with memory race conditions better than C, and managed languages are not fit for kernel. This isn't the fault of C at all. These kinds of issues are unavoidable part of kernel programming in multiprocessor settings and not something you can solve with a different programming language. This comment just can't be more wrong.

IshKebab 3y ago
Rust deals with race conditions 100 times better than C. Have you tried it? Just because it can't guarantee that they never happen doesn't mean it isn't any better. You can't solve this with a different programming language but you can definitely make bugs much less likely.