• 0 Posts
  • 24 Comments
Joined 2 years ago
cake
Cake day: June 14th, 2023

help-circle




  • Your argument is completely specious. Re-read that list. Assembly is a second language in the kernel already, and really it’s multiple languages, one per supported ISA. Perl and Python scripts are used to generate data tables; there are multiple build-time languages. eBPF is evaluated at runtime; the kernel contains bytecode loaders, JIT compilers, and capability management for it. The kernel has already paid the initial cost of setting up a chimeric build process which evaluates many different languages at many different stages.







  • I am not a programmer. … I’m a random with a chimp avatar. … It’s just that [Hellwig] prioritises consistency (for the sake of maintainability)…

    Pick a side and stick to it. You seem very keen to endorse Hellwig’s arguments despite not understanding them, and also to emit words on the topic despite not having a qualified opinion. It sounds like you want me to not take you seriously (so that I won’t reply to you) and also take you seriously (so that you are counted as part of the programming public.)

    I’m docking you again, this time for listening comprehension. Quoting Gaynor:

    The common thread here is that for each of [six listed vulnerabilities exploited by nation-states against vulnerable minorities], the vulnerability that was executed … was only possible because of the victim’s software being written in a memory-unsafe language. Put another way, if the relevant portions of these projects were written in a safe language, these vulnerabilities wouldn’t have been possible.

    That was early in the talk, around 6:30. Later, around 19:40, he says:

    The Rust-for-Linux project is working to make it possible for people to write Linux kernel modules in Rust.

    So, if you had watched Gaynor’s presentation, you would understand that Rust-for-Linux is a significant and prominent part of a wider push by security professionals to improve the overall safety of common devices, like Android phones, that are in the pockets of millions of people already. And then you wouldn’t be talking about respectability politics while apologizing for reactionaries who oppose that safety.



  • Your position is entirely reasonable and an excellent example of how ignoring technical details leads to failures of technical leadership. C is one of several languages notable for extreme lack of memory safety. Its lack of safety has been repeatedly quantified; I like to recommend Gaynor 2021 for a high-level introduction. Rust was introduced primarily to replace C (and a relative, C++) and improve the overall security of computing systems.

    The “merits of the project Rust4Linux” are simple and obvious: as code is translated from C to Rust, its overall characteristics (readability, performance, low-level modeling of machine behavior) will remain, but overall memory safety will increase. Opposition to it is reactionary, not well-grounded in technical merits; most of Linux is not well-proven to be correct, only believed to be correct under typical operating conditions as estimated by several dozen experienced programmers, and any technical options for improving our confidence in its correctness should be considered.

    Also, finally, I have to dock you for reading comprehension. Martin was quite clear: calling Rust a “cancer” – a cute pun given Rust’s crab mascot, or a dehumanizing slur, who knows – was, to them, a violation of the Code. It is not difficult to read the Code and notice that, were it a slur, it would violate the prohibition on “insulting/derogatory comments, and personal or political attacks.”





  • I might prototype a workflow with this tool, but I don’t really have any problems that it would solve. Connectivity to my machines is established with overlay networks and isn’t a problem; I’d rather read a Prometheus dashboard than connect to individual machines, and I’d rather sit back and know that everything is working within acceptable parameters and metrics than repeatedly probe parts of the system.

    Some of the features feel like they can never be made secure; in particular, it’s not clear how XPipe changes the threat model for attacks which start by compromising a single development environment, other than being a large obvious target. File transfer is another good example; every connection protocol either already has file transfer or it doesn’t, and for two Internet-connected machines I can always fall back to Magic Wormhole. Similarly, while it’s important to know how to get into a Kubernetes Pod, it’s usually a security problem to have one-click SSH access to hundreds of them.

    I’m telling you this mostly because of the open-core note. I genuinely cannot imagine recommending XPipe for purchase in any scenario, and I don’t know how much that will change after prototyping a workflow. Shops that have needed tools for managing thousands of machines/sysadmin usually are willing to do the in-house development to build in-house tools. Over the past decade, GIFEE (“Google’s infrastructure, for everybody else”) has resulted in first Prometheus and now (I guess) OpenTelemetry making it possible to have good observability on tiny, small, and medium systems with a single observatory. It also shouldn’t surprise you that I’m not going to recommend XPipe outside of a work context or encourage folks to contribute to it; there’s no point in building a community around a closed project.