Live data from Hacker News

The Case for Rust in the base system

mail-archive.freebsd.org

121–130 of 155 posts

Re: The Case for Rust in the base system

#121
post #90

Earlier quoted context omitted.

Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-saf... These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily…

Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour: It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety. There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe. Additionally, it’s not Google overall, but chromium project that find this, as we…

> not Microsoft overall, but specifically Windows

This isn't the case: https://msrc.microsoft.com/blog/2019/07/a-proactive-approach...

> Since 2004, the Microsoft Security Response Centre (MSRC) has triaged every reported Microsoft security vulnerability.

They've never qualified it as Windows only, to my knowledge.

Re: The Case for Rust in the base system

#122

Earlier quoted context omitted.

One of the biggest things about Rust for me is that it's essentially Prometheus, bringing the fire of modern languages and more advances PL theory to systems programming, which imo is sorely needed. We don't need a 10% better C or C++, we need a huge jump for the field. Rust I think does this. They have: 1. A type system that's deeply inspired by OCaml, a language that's designed and used by a lot of programming lang…

>2. got amazing, highly flexible and generalized iterator and monad support (you can use iterator methods on monads), basically second only to Haskell itself, that compiles down to the equivalent of hand written assembly code loops As I understand it, Rust lacks do-notation and higher-kinded types, making it hard to have true monads in Rust. Scala would be the language with monad support comparable to Haskell.

My understanding is that Rust lacks the ability to have a generic Monad abstraction like Haskell and Scala, but that it certainly has monads (e.g Option, Result, Vec, etc). And indeed that even languages like JavaScript have lots of monads (e.g. Promise) it's just that these are likewise not abstractable.

I believe that a monad is basically any container that has both a constructor and a flat_map function (and there may be one other requirement that I've forgotten). The special ability that Haskell has is the ability to write code that is generic over any such container.

Re: The Case for Rust in the base system

#123
post #85

Earlier quoted context omitted.

Yeah, the architecture point comes up in lost of rust in core type discussions, but I think when it comes to the BSD's it's actually a critical argument. I'm not particularly excited by limping along unusual architectures that most of the contributors can't perform reproductions on, but the BSD's are a bastion in this space and something probably has to be. Addressing this issue in both Rust and LLVM would be valuabl…

Even arm32 and x86 are Tier 2. Not exactly unusual architectures. The only Tier 1 architectures are amd64 and arm64, i.e. only the absolute mainstream. Not exactly a bastion of architecture support.

> Even arm32 and x86 are Tier 2. Not exactly unusual architectures.

There is 32-bit x86 tier 1 targets like i686-unknown-linux-gnu.

> The only Tier 1 architectures are [...] only the absolute mainstream. Not exactly a bastion of architecture support.

Tier 1 means that the target has the full testsuite run against it for each single pull request. Running the CI is computationally extremely complex, and it is hard to provide a reliable and fast CI service for most architectures.

Re: The Case for Rust in the base system

#125

Earlier quoted context omitted.

The Curiosity rover might be doing ok, but the many places that have my social security number are not. I care more about the latter than the former.

Right—and maybe those places ought to install OpenBSD. https://www.openbsd.org/ Rust is not immune to security vulnerabilities. And at the end of the day, social engineering will steal more data than "hacking the mainframe". Why break in when you can just ask to be let in? OpenBSD has a great security track record because they resist excessive change and prefer simplicity . For those who want to add Rust to the core…

[deleted]

Re: The Case for Rust in the base system

#126
post #90

Earlier quoted context omitted.

Microsoft, Google, and other companies have all determined that about 70% of CVEs are memory-related. Here's the US government's take: https://www.cisa.gov/news-events/news/urgent-need-memory-saf... These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily…

Just to avoid any “cyclist rides more aggressively when wearing helmet” type behaviour: It’s probably worth nothing that that vast majority of, and of large scale attacks, is basic shit that has nothing to do with memory safety. There’s benefit to memory safety, but just cause you’re wearing a helmet doesn’t mean you’re completely safe. Additionally, it’s not Google overall, but chromium project that find this, as we…

[deleted]

Re: The Case for Rust in the base system

#127
post #54

Earlier quoted context omitted.

If these architectures can't muster enough manpower to keep up with modern toolchains then they are living on borrowed time. Maintainers of active, modern development projects have a limited tolerance for anachronism before they say "get a modern toolchain up and running or get left behind, we're sick and tired of C89".

I feel like that might leave embedded devices without an upgrade path, and those are the devices that needs to longest "warning". So yes, borrowed time, but that might be a decade. That no to say that Rust shouldn't be considered, but maybe initially for new development or selective rewrites. Some of the mentioned, like nscd or devd in particular, shouldn't be that high on the list. The ZFSd should be fairly safe, as…

I feel like those are the kinds of devices that never get manufacturer updates anyway. And even if they did, the manufacturer likely is no longer supporting them.

Sure, it's nice to be able to tinker and hack to see if you can upgrade them yourselves, but is it worth maintaining architecture support for that kind of use case? Not asserting that is definitely not, but I think it's worth considering.

Re: The Case for Rust in the base system

#128
post #123

Earlier quoted context omitted.

Even arm32 and x86 are Tier 2. Not exactly unusual architectures. The only Tier 1 architectures are amd64 and arm64, i.e. only the absolute mainstream. Not exactly a bastion of architecture support.

> Even arm32 and x86 are Tier 2. Not exactly unusual architectures. There is 32-bit x86 tier 1 targets like i686-unknown-linux-gnu. > The only Tier 1 architectures are [...] only the absolute mainstream. Not exactly a bastion of architecture support. Tier 1 means that the target has the full testsuite run against it for each single pull request. Running the CI is computationally extremely complex, and it is hard to p…

I meant ... the FreeBSD tiers.

Re: The Case for Rust in the base system

#129
post #17

Earlier quoted context omitted.

Rust‘s type system prevents memory safety bugs because it reasons about object lifetimes statically. At the same time rust allows you to write systems code on bare metal.

> it reasons about object lifetimes statically. How does that differ from RAII? I think i misunderstand you or lack knowledge, because this sounds exactly like RAII. I know that rust has major compile time checks, but saying that the difference is that it reason about life time as difference to c++ is misleading. I think the major point of c++ compared to c is that c++ "reason about object lifetime statically" with d…

Yeah if you never use a pointer/reference/iterator, the guarantees are quite similar. The rust compiler however also checks for use after free and iterator invalidation bugs. In addition it makes it harder to shoot yourself in the foot in concurrent code because you can’t have multiple mutable references to an object.
Post reply on HN