3 ms·

> This approach avoids the overly restricted verification requirements (e.g., program complexity constraints) Maybe i'm missing something, but isn't that a bad

by bawolff 10mo ago

> This approach avoids the overly restricted verification requirements (e.g., program complexity constraints) Maybe i'm missing something, but isn't that a bad thing?

pjmlp 10mo ago
Yes, very bad, even worse when coming from supposedly security conscious programming language community.
- NewJazz 10mo ago
  They're not in the core language group... Do these people have influence in the stdlib, compiler, prominent libraries? Kernel community? Why judge the whole Rust community for the choices made by one minor subgroup?
  - testdelacc1 10mo ago
    It’s a common HN trope to generalise a “community” based on a handful of people or even just one person. “See this is why I dislike the xyz community”, says a person justifying their confirmation bias. Perhaps the world is too complex without breaking it down into in-groups and out-groups, with any out-groups supposedly being completely homogenous. Pretty intellectually lazy but fairly common on HN, to the point where it’s not even worth calling out.
    - johnisgood 10mo ago
      I mean, I was going to reply "take a wild guess" to him, but your message is correct, too. (I may come across as an Ada zealot myself.)
      - nickpsecurity 10mo ago
        Quick, random question. I heard way back that SPARK was getting safe pointers in response to Rust's borrow checker. Has full Ada solved their unsafe de-allocation problem in a way that's comparable to the borrow checker's guarantees?
        johnisgood 10mo ago
        Yes, it was introduced many years ago and has been in production for quite some time now. You can completely eliminate use-after-free, double-free, dangling pointers, memory leaks, and null dereferences. You should take another look, lots have changed in this scene.
    - jacquesm 10mo ago
      You may be correct but pjmlp is not one of those and if you had been here long enough you would have known that. You're the one creating an in-group here and putting yourself on the 'good' side. Perhaps that is too complex for you but I think it is intellectually lazy not to get who you're referring to before making comments such as these. Note that your strawman "See this is why I dislike the xyz community" wasn't part of this thread at all.
      - pjmlp 10mo ago
        A community is made by all of its participants. One could also say some in the C or C++ communities actually care about security, thus no need for Rust or alike, yet no one is paying attention to those small groups in the corner. A village is judged by its population actions, and even the black sheeps count to its overall image from outsiders.
        jacquesm 10mo ago
        Indeed. If there is one person here that keeps their footing in language debates it is you (and I'm always blown away with how many details you have at instant recall that I never realized were there). So thank you for the lessons over the years, it has helped me evaluate my choices better. As for that sentence: I think Rust has its place, I do not agree at all with their 'rewrite' mantra because there are a ton of risks associated with rewrites that have nothing to do in what language the code is written in, just that it is a rewrite. I think the Rust folks should go all-in on Redox and fix their tool optimization issues. And do one thing and do that well rather than to be the next Swiss army knife of programming. And I also think that the C and C++ folks can do a lot better still. Filip is doing something interesting I think and if there a practical solution to the C heritage I think it lies more in his direction than in rewriting billions of lines of battle tested code. Performance isn't nearly as important as it used to be. Another thing that I think would be beneficial would be to take as many device drivers out of the linux kernel as possible and run them as userspace processes. Anyway, belated Merry Christmas to you and a pre-emptive happy 2026!
        10mo ago
  - deleted 10mo ago
    [deleted]
  - pjmlp 10mo ago
    Because the actions of everyone count to the wide perception of a community from the outside. Rust Striking Force meme exists for a reason, their actions are also not supported by the core team.
    - monocasa 10mo ago
      Do they interact at all with the main rust community? It seems a little disingenuous to describe "community" as including people who haven't even attempted to interact with anyone in the community other than forking their code.
    - ksec 10mo ago
      >Rust Striking Force meme exists for a reason, their actions are also not supported by the core team. Many of the core team and by large its community witness RESF in action for long before sending in a few words isn't exactly not supported in my book. But then again I understand every PL needs a lot of push and marketing. It just went way too far in one direction.
  - pseudony 10mo ago
    This has been covered ad nauseam, but since rust advocacy has waded into enough discussions about code in other languages to lecture people on performance and safety, it has naturally pushed some to find a bit of satisfaction in commenting on shortcomings in rust projects. And this is very much also something which is helped along by the community’s defining voices.
- convolvatron 10mo ago
  I reflexively downvoted you. There has to be room for the evolution of operating systems and the maturation of new systems developers. this division of code into 'things we're allowed to understand' and 'the magic that we can't touch' has really been counterproductive for everyone. but I realized that in the past decade or so all of my kernel experiments are being done in little baby kernels. virtualization and the sheer volume of open source makes this a perfectly good path. and frankly Linux isn't that lovely to work in and extend. the current situation with kernel modules and symbol resolution is a crappy boundary that really gets in your way as a developer, and from a security perspective is really just crime scene tape. so we should really try to clean up and harden production systems, and understand that we will need the playground to inform that activity. right now we have neither, and this clearly belongs in the playground.
deleted 10mo ago
[deleted]
otabdeveloper4 10mo ago
"Bad thing" is an understatement.
IshKebab 10mo ago
The things you're missing: 1. This requires root. 2. eBPF also requires root usually. As I understand it it was originally meant to be secure enough to allow unprivileged use but Spectre ruined that and now they've given up on that.
- p-e-w 10mo ago
  How would Spectre, a timing attack that does not require root, affect whether eBPF is safe to run as root?
  - IshKebab 10mo ago
    It doesn't. Spectre means unprivileged use of eBPF is insecure.
viraptor 10mo ago
Depends. If you want to implement a very fancy kernel level tracing tool for your local environment, why would it be a bad thing? Worst case you'll lock up your system and have to reboot. But you wouldn't want to use that for the actual firewall for example, or with a production service. There's no general "bad". Just different contexts.

by bawolff 10mo ago

> This approach avoids the overly restricted verification requirements (e.g., program complexity constraints) Maybe i'm missing something, but isn't that a bad thing?

pjmlp 10mo ago

Yes, very bad, even worse when coming from supposedly security conscious programming language community.

NewJazz 10mo ago
They're not in the core language group... Do these people have influence in the stdlib, compiler, prominent libraries? Kernel community? Why judge the whole Rust community for the choices made by one minor subgroup?
- testdelacc1 10mo ago
  It’s a common HN trope to generalise a “community” based on a handful of people or even just one person. “See this is why I dislike the xyz community”, says a person justifying their confirmation bias. Perhaps the world is too complex without breaking it down into in-groups and out-groups, with any out-groups supposedly being completely homogenous. Pretty intellectually lazy but fairly common on HN, to the point where it’s not even worth calling out.
  - johnisgood 10mo ago
    I mean, I was going to reply "take a wild guess" to him, but your message is correct, too. (I may come across as an Ada zealot myself.)
    - nickpsecurity 10mo ago
      Quick, random question. I heard way back that SPARK was getting safe pointers in response to Rust's borrow checker. Has full Ada solved their unsafe de-allocation problem in a way that's comparable to the borrow checker's guarantees?
      - johnisgood 10mo ago
        Yes, it was introduced many years ago and has been in production for quite some time now. You can completely eliminate use-after-free, double-free, dangling pointers, memory leaks, and null dereferences. You should take another look, lots have changed in this scene.
  - jacquesm 10mo ago
    You may be correct but pjmlp is not one of those and if you had been here long enough you would have known that. You're the one creating an in-group here and putting yourself on the 'good' side. Perhaps that is too complex for you but I think it is intellectually lazy not to get who you're referring to before making comments such as these. Note that your strawman "See this is why I dislike the xyz community" wasn't part of this thread at all.
    - pjmlp 10mo ago
      A community is made by all of its participants. One could also say some in the C or C++ communities actually care about security, thus no need for Rust or alike, yet no one is paying attention to those small groups in the corner. A village is judged by its population actions, and even the black sheeps count to its overall image from outsiders.
      - jacquesm 10mo ago
        Indeed. If there is one person here that keeps their footing in language debates it is you (and I'm always blown away with how many details you have at instant recall that I never realized were there). So thank you for the lessons over the years, it has helped me evaluate my choices better. As for that sentence: I think Rust has its place, I do not agree at all with their 'rewrite' mantra because there are a ton of risks associated with rewrites that have nothing to do in what language the code is written in, just that it is a rewrite. I think the Rust folks should go all-in on Redox and fix their tool optimization issues. And do one thing and do that well rather than to be the next Swiss army knife of programming. And I also think that the C and C++ folks can do a lot better still. Filip is doing something interesting I think and if there a practical solution to the C heritage I think it lies more in his direction than in rewriting billions of lines of battle tested code. Performance isn't nearly as important as it used to be. Another thing that I think would be beneficial would be to take as many device drivers out of the linux kernel as possible and run them as userspace processes. Anyway, belated Merry Christmas to you and a pre-emptive happy 2026!
        10mo ago
- deleted 10mo ago
  [deleted]
- pjmlp 10mo ago
  Because the actions of everyone count to the wide perception of a community from the outside. Rust Striking Force meme exists for a reason, their actions are also not supported by the core team.
  - monocasa 10mo ago
    Do they interact at all with the main rust community? It seems a little disingenuous to describe "community" as including people who haven't even attempted to interact with anyone in the community other than forking their code.
  - ksec 10mo ago
    >Rust Striking Force meme exists for a reason, their actions are also not supported by the core team. Many of the core team and by large its community witness RESF in action for long before sending in a few words isn't exactly not supported in my book. But then again I understand every PL needs a lot of push and marketing. It just went way too far in one direction.
- pseudony 10mo ago
  This has been covered ad nauseam, but since rust advocacy has waded into enough discussions about code in other languages to lecture people on performance and safety, it has naturally pushed some to find a bit of satisfaction in commenting on shortcomings in rust projects. And this is very much also something which is helped along by the community’s defining voices.
convolvatron 10mo ago
I reflexively downvoted you. There has to be room for the evolution of operating systems and the maturation of new systems developers. this division of code into 'things we're allowed to understand' and 'the magic that we can't touch' has really been counterproductive for everyone. but I realized that in the past decade or so all of my kernel experiments are being done in little baby kernels. virtualization and the sheer volume of open source makes this a perfectly good path. and frankly Linux isn't that lovely to work in and extend. the current situation with kernel modules and symbol resolution is a crappy boundary that really gets in your way as a developer, and from a security perspective is really just crime scene tape. so we should really try to clean up and harden production systems, and understand that we will need the playground to inform that activity. right now we have neither, and this clearly belongs in the playground.

deleted 10mo ago

[deleted]

otabdeveloper4 10mo ago

"Bad thing" is an understatement.

IshKebab 10mo ago

The things you're missing: 1. This requires root. 2. eBPF also requires root usually. As I understand it it was originally meant to be secure enough to allow unprivileged use but Spectre ruined that and now they've given up on that.

p-e-w 10mo ago
How would Spectre, a timing attack that does not require root, affect whether eBPF is safe to run as root?
- IshKebab 10mo ago
  It doesn't. Spectre means unprivileged use of eBPF is insecure.

viraptor 10mo ago

Depends. If you want to implement a very fancy kernel level tracing tool for your local environment, why would it be a bad thing? Worst case you'll lock up your system and have to reboot. But you wouldn't want to use that for the actual firewall for example, or with a production service. There's no general "bad". Just different contexts.