12 ms·

“Rewrite It in Rust” Considered Harmful? [pdf]

117 points by libele 3y ago

pictur 3y ago
In the software world, there is no other cancer mass like the mass that constantly recommends anything.
gemstones 3y ago
As a hobbyist with only limited C++ and Rust experience, reading things like the abstract of this paper push me towards Rust a bit. The snark is really offputting. As a user of software trying to protect my personal information in an increasingly threatening world, I would like memory safety in more places. From the outside looking in it feels like there are a lot of C and C++ programmers trying to deflect from how poorly their attempts at memory safety have gone and just snarking at the people trying to fix it. I will say that the point about FFI boundaries needing more care is a valid one I had not considered. Is there a name for people who don't work in C++ and never, ever hear "rewrite it in Rust" except from programmers who seem like they're a bit hurt that their language has a competitor?
- lesuorac 3y ago
  The other part I find amusing is that the issues found in the paper is that not enough was rewritten into Rust!! The first F in FFI [1] means that you have an interaction of non-Rust and Rust. (Or two non-Rust languages but that's moot). [1]: https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface
  - cogman10 3y ago
    Yeah, it's a bit like saying "See, Java isn't memory safe! Look what happens when we expose native methods and calls between the JVM and C!" FFI is inherently unsafe regardless of language.
- JohnFen 3y ago
  > their language has a competitor? I take issue with the notion that languages can have competitors. Languages are tools, and some languages are more suited to some tasks than others, but each has their place. Saying languages compete with each other is a bit like saying different kinds of hammers compete with each other. They don't, each is just optimized for a different kind of hammering.
  - nindalf 3y ago
    Thinking of languages as hammers or screwdrivers is too simplistic. Instead, think of languages as platforms. Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning its ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment. More adoption => more libraries => more projects => more jobs => more adoption. A virtuous cycle. This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy. It's also partly because they've spent so working with this language that it's become a part of their identity. A critique of the tool is perceived as an attack on the person.
    - JohnFen 3y ago
      I suppose my views are skewed because I have become competent or better in a large number of languages. I have my favorite general-purpose language, of course (it's C++-as-a-better-C), but I view choosing a language for a particular project to be an engineering decision that I make according to the demands of the project, not based on what language I personally enjoy the most. Developers do get emotionally invested in their tools, and I've seen an uncountable number of holy wars because of that. But all of them strike me as being ludicrous. If another dev uses a language I would not have chosen, that's not a personal affront to me. I assume they made an engineering decision that made sense for their situation. It's all good. > If it did, their language's viability is threatened and their investment is in jeopardy. I sorta see this, but in my experience, it's very easy to overstate this case. If a language is viable enough to develop in initially, it's viable. How popular it is or becomes isn't really that important except in terms of being a business decision ("is it possible to hire people in the future who know this language?")
- __s 3y ago
  There isn't a name for you, but what you're experiencing is strawman attacks Like the strawman argument where it creates a flawed argument to declare victory over, the strawman attack picks out the most extreme case to declare victory over You'll see this done on left/right political debates where instead of recognizing that most people can find agreeable common ground on 80% of issues, extreme advocates will pick out the opposing extreme advocates to vilify each others' groups I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass
  - carlmr 3y ago
    >I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass That's true, however IME C++ programmers are the most in denial. And yes, RAII has helped a lot. But still we see way too many memory errors coming from C++ code bases.
  - avgcorrection 3y ago
    Arguing isn’t a game of diplomacy and middle grounds.
  - uecker 3y ago
    A a C programmer, I think Rust got memory correctness right. Unfortunately, I do not like the rest of the language ;-(
- prpl 3y ago
  it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs - and are probably directly protecting an order or two magnitude more of your personal data than Rust and C++ - even without discussing relatively safe languages (interpreted but with various implementations) like Python, PHP, and Ruby.
  - nordsieck 3y ago
    > it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs While that's true, memory safety bugs are particularly dangerous from a security perspective.
  - kimixa 3y ago
    In my experience a memory error is often the result of a logic bug - that is the "first failure" of an existing issue in C++ is a memory error, but the originating logic error still exists and would just cause a different issue under "memory safe" languages. It would still be a bug, and may cause security issues. IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between. The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
    - Verdex 3y ago
      The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.
- pkulak 3y ago
  "Rewrite it in Rust" is another class of "I use Arch, BTW"; one of those phrases no one has ever actually heard unironically, and that is only used to attack the strawman who supposedly said it.
  - hxugufjfjf 3y ago
    Sorry to disappoint, but try searching for that on Github and see the amount of projects where this has been unironically suggested.
- marcosdumay 3y ago
  Not long ago surgeons didn't have a rule of washing their hands before doing an intrusive surgery, and lots and lots of people died because of that. At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients... Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.
  - akprasad 3y ago
    https://en.wikipedia.org/wiki/Ignaz_Semmelweis https://en.wikipedia.org/wiki/Ignaz_Semmelweis > Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.
  - fasterik 3y ago
    This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.
    - 3y ago
- vpastore 3y ago
  it look like you can use this. https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s This talk is what convinced me to move to Rust definitely. The audience is the perfect representation of the C++ community.
- lohnjemon 3y ago
  How does memory safety allow you to protect your personal information? How many binary exploits have actually lead to the exposing your personal information? I can count with my fingertips exactly zero times that has happened to me. The times my personal information was compromised happened to me is when I downloaded malicious software. Malicious software doesn't care whether your process has "memory safety", it'll extract anything from the processes memory it wishes. Sure memory safety would at least rule out simple binary exploits, but to be targeted by one is not exactly common. I don't get the narrative of an ever increasingly threatening world. If anything things have only been getting better, at least for the individual users. I remember individuals getting pwned very frequently in the old days. Now, not so much, with DEP, ASLR, and stack canaries. The attacks on businesses have increased, but those attacks are mostly just phishing or otherwise human error related. Attack vectors for actual PI retrieval rarely incorporate some obscure memory bug in a program allowing RCE or remote access. Unless you're a high value target.
  - insanitybit 3y ago
    > How many binary exploits have actually lead to the exposing your personal information? It happens with some frequency. WhatsApp was exploited due to a memory safety vulnerability, for example. Chrome 0days for memory unsafe vulns are definitely exploited in the wild. Typically companies have much much larger attack surface, so a technique like phishing is going to be far cheaper to execute. But even still, I've seen a memory safety vulnerability used in an attack against a company. The thing is that most companies' attack surface isn't in C/C++ because... that would suck, so they don't do it. Or if they do they use a specific codebase that's been heavily invested in over decades and they sandbox and isolate the services. So on the one hand, yes, most attacks on companies are not due to memory safety issues but that's in part because of the investments into memory safety. > I remember individuals getting pwned very frequently in the old days. Yep, significant efforts were made to make the internet a safer place. Primarily the sandboxing and disabling of third party plugins in browsers. But this doesn't really matter. Yes, there are other issues like phishing and those are being addressed with other techniques. There are issues like sql injection and those are also being addressed. That doesn't mean that memory safety isn't an issue.
kstenerud 3y ago
OMG please, enough with the "X considered harmful". It just makes me not want to even look at it.
- RealityVoid 3y ago
  Considered harmful articles considered harmful.
- faitswulff 3y ago
  I present to you “Considered Harmful” Essays Considered Harmful: https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
- codelikeawolf 3y ago
  Preach! It's only a matter of time before "Considering 'Considered Harmful' harmful considered harmful" shows up.
serverholic 3y ago
I really don’t understand the people who have a problem with rust. Do you not value the increased memory safety? Now that Microsoft and Google are adopting rust and reporting significant decreases in memory related bugs it’s pretty clear that rust does make a difference.
- maleldil 3y ago
  Rust restricts what you can do when it can't reason about your code. Some developers don't like those restrictions and feel like they're "fighting the borrow checker". Others don't think it's worth it and go back to managed languages. It's usually something like "I don't need the compiler holding my hand, I know what I'm doing", or "I'll just write in Go/Java/etc. so I don't have to worry about memory".
- signaturefish 3y ago
  TBH, I don't have a problem with Rust so much as I have/had a problem with a section of the rust community. The shouting fanbeings of rust put me off looking into it for years, because when I kept getting "rewrite it in rust!" as the answer to "there's a problem with $THIS_CODE" when talking with colleagues, _even when those colleagues had minimal rust experience_, all I could conclude was that the whole thing was an empty promise and that no-one knew how to solve the problem, but everyone "knew" that the New Cool Language was the way to fix everything. Generalisation from incomplete data - no doubt there was a sensible majority in the rust community, but the fanbeings were _loud_. FWIW I was wrong: I'm getting into rust now and I like what I see, and the discussions around it online and with colleagues are pretty sensible. But, it's taken a while to get there and when you've been in tech for a couple of decades you see this hype cycle and get jaded to it. Erlang is the new hotness ... OCaml is the new hotness ... Java is the new hotness, rewrite everything in Java, wait C# is the new hotness... I suspect rust is here to stay, and I'm gonna learn more about it, and I regret some of my past words about it. But my problem was never with the increased memory safety, or the language at all, pretty much, just the early community. TL;DR: Other humans are the worst, bug reported, fix unlikely :)
  - pdimitar 3y ago
nindalf 3y ago
There's a certain tendency to take anything written in a double column PDF followed by a long list of citations as gospel. Maybe that's what the authors were hoping for? The poor quality of writing, contrived examples and unnecessary snark could be why the authors didn't to put their name to this paper.
Verdex 3y ago
Ah yes, the "* Considered Harmful" tradition in computer science. A tradition so widespread that it has even wrapped around upon itself and yielded the "'Considered harmful' considered harmful" paper. Not the best start already. Hmm, written by 'Anonymous Authors'. So is this supposed to be a joke? Is the implication that speaking out against rust makes you the target of unjust persecution? Is it written by people known to have an axe to grind? Abstract: This is a free-verse poem setting up a rust advocate strawman. Do such people exist on the internet? Yes. But time cube also exists on the internet. Introduction: Incrementally rewriting a C/C++ system in rust is bad because FFI can have problems. Which can be simplified with a different spin to be, "C/C++ are so bad that they contaminate even the mighty rust." It feels like the paper might have some good information that would be useful to people who want to augment their codebases with rust. However, it starts off so combative, that I don't think I could seriously recommend anyone actually read it. Maybe just skip the abstract and intro and see what you get out of it?
- remexre 3y ago
  "Anonymous Authors" is typical for a pre-print that might be sent out for blind peer review.
  - vngzs 3y ago
    The only publication that might take this paper without changes is POC||GTFO. Did you read the abstract?
  - Verdex 3y ago
    Interesting, TIL. Follow up question then: Is it normal for pre-prints that go out for blind peer reviews to be publicly posted like this? Should I be interpreting this as a leak of some sort, someone trying to get their work public eyeballs without messing with the peer review, etc? Or is this just par for the course in academia?
- spoiler 3y ago
  > Which can be simplified with a different spin to be, "C/C++ are so bad that they contaminate even the mighty rust." I've written C and C++ for a long time, and... Alas, you're not completely wrong lol. At work there's a still unresolved ticket of me trying to get cross compilation working, and it's basically impossible because of the way most C/C++ tooling is built and works. CLang kinda works nicer here than GCC, but there were other issues with that that I encountered. Basically, it's nearly unsolvable due to the number of hoops one needs to jump to properly link against a dynamic library produced for the target platform (if the host platform is different).
ericseppanen 3y ago
"we model a scenario where the original code is memory-safe; the ported code is memory-safe; and we consider memory safety and undefined behavior that may arise across the FFI layer between the two pieces of code." I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space. But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary. If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.
- JodieBenitez 3y ago
  > But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards What if someone makes a strawman out of memory problems so they can rewrite it in Rust ?
  - awestroke 3y ago
    Great, let them do whatever they want
- Szpadel 3y ago
  agree, i wanted to just add that this paper might be right for projects that are not actively developed anymore something like bash or coreutils etc, as there this is fairly well tested code and there aren't that many added features that could introduce issues. for anything that is actively developed it's a whole other story, even if you are confident that the current codebase is safe, each added feature has a risk that it breaks some unwritten contract somewhere and introduces security issues. eg. look at recent vulnerability in sudo, at and second sight it was safe and secure, triggering it required unobvious corner case. how many of similar issues you could have in your codebase that could be dormant for years?
duped 3y ago
The authors don't seem to understand memory safety or FFI and wrote a contrived article about it. Hell, the first example isn't equivalent code. You can't share references across an FFI boundary with C.
woodruffw 3y ago
I'm possibly misunderstanding, but their first example doesn't make sense to me: 1. C can make aggressive aliasing optimizations based on observable behavior, meaning that the compiler may or may not optimize `add_twice` based on the results of any alias analysis it chooses to do. In other words: the author's assumption that a C compiler won't optimize `add_twice` in the same way that Rust will is not a guarantee, and assuming that it won't is relying on unspecified behavior. 2. The author claims that the result of the optimization can result in memory unsafety, and it's not immediately clear to me that that's true: it might be true in an interprocedural sense due to another function's assumptions about how `add_twice` affects its parameters, but this is the same incorrect assumption as in (1). In that sense, Rust is not really involved at all here.
- pornel 3y ago
  In Rust mutable references are exclusive. They're statically guaranteed to never alias with any other pointer. However, when you call such function from C, the C compiler has no clue about exclusive references, so obviously it can't enforce their invariants. The C side can provide aliased pointers and break Rust's assumptions. The Rust side assumes it's called correctly, and the C side can't know what is correct.
  - woodruffw 3y ago
    Right, but that's not controversial, is it? If you call into Rust from C, you need to preserve Rust's invariants; Rust can't preserve them for you.
    - pornel 3y ago
      I don't think anybody expects incorrect code to behave correctly, but as usual the issue is about mistakes. The C compiler can't help you preserve Rust's invariants, so when you make wrong assumptions or declare a wrong interface, instead of a compilation error, you can get UB silently creeping in. The FFI-glue language they propose is meant to prevent these types of mistakes.
- 3y ago
holmesworcester 3y ago
A lot of the commenters don't seem to understand the thrust of this paper. First, the use of "considered harmful" here is tongue-in-cheek or at least self-aware. Second, the point of the paper is not to say that rewriting in Rust is bad, but to propose a safer approach to incremental rewrites that addresses (what the authors argue is) the risk of introducing new bugs at the C/Rust boundary.
genr8 3y ago
now here we have "X considered harmful" - a common Trope. This seems more like a "First!" to title their paper this, as a meme of the whitepaper meta, that title came first, then the arguments came. I say this because I joked about a paper being released with this name about a week ago and now here it is, but Its a bit lower quality than expected. We might need another one later...
dcsommer 3y ago
There's plenty of good content in this paper. FFI safety is a very important topic, and there are unique concerns with Rust FFI. Such a shame it devolves into unprofessional and inflammatory remarks. The authors could have put their names on the paper and gotten a decent credit if they could have kept their emotional responses to the topic out of it.
- cogman10 3y ago
  The problem I have with this article is it's pointing at a universal problem (FFI safety) and narrowing that to a rust problem. Yes, FFI is dangerous, that's true regardless of language (including C). FFI is inherently platform, language, and even compiler specific. It's super tricky to get right.
lucideer 3y ago
> Anonymous Authors Because no-one would want to put their name to this. There may be some valid arguments in there (though it seems to be just "FFI is hard ergo noone should never attempt phased migration of any system codebase"), but even content aside, the tone is that of a moody teenager. The abstract in particular is one of the worst things I've ever read - the introduction doesn't read fantastically eitherr.
alex_lav 3y ago
"Rewrite it in ____" should pretty much always be a last restort. Rewriting takes a ton of time and effort, has its own downsides, and just generally doesn't have as obvious a value add to customers/consumers (outside of pretty specific scenarios) to justify the cost. Plus, rewriting anything in anything else just invites a whole new suite of problems with the new thing that probably/definitely weren't accounted for. Now, for personal software I say hell yes. If a person is writing code for the fun of it, or simply wants to learn about concepts, rewrite whatever in whatever and have a great time. That's the point! But for professional/commercial software, rewriting is probably more expensive than is realized.
dmkolobov 3y ago
I think some folks are misreading the authors intentions(possibly due to aforementioned snark): they’re not advocating for sticking to existing C codebases over rust. They identify FFI as an area where it is easy to make mistakes which lead to undefined behavior, argue that it is the result of competing assumptions between C and rust, and then propose a formal system implemented in both in C and in Rust to resolve those issues. Sure, the problems they identify wouldn’t exist if everything was rewritten in Rust, but on a large enough / old enough codebase, that may impossible to do all at once. This paper attempts to find a way to make rust better within those organizational constraints. The audience here is not engineering managers deciding in your next tech stack, but programming language researchers.
- Verdex 3y ago
  > I think some folks are misreading the authors intentions(possibly due to aforementioned snark) Yes. It looks like the paper has some useful things to say. However, that abstract + intro is like walking into a wedding and splashing red paint on the bride and then announcing a bunch of very good reasons why the wedding should not continue. Nobody is going to be listening. Perhaps another way to say it is that nobody is misreading their intension. What they're doing is ignoring reasonable concerns said in an unreasonable way.
  - dmkolobov 3y ago
    I’m not a fan of “being cute” in papers typically, for the reason that it detracts from the central ideas. Clearly this happened here. These discussions frequently feel “tense”, wherein criticisms based on specific technical details are tied to an attack on the language as a whole. In that context, the authors definitely shot themselves in the foot with the opening/title.
  - soqb 3y ago
    it seems under this view, the conclusion that can be drawn for the paper is “replacing parts of a C codebase with the conceptually equivalent Rust code without any thought as to the nuances of Rust ffi may lead to bugs if the C code is already contrived” which doesn’t seem too useful a conclusion to me.
pornel 3y ago
Although the paper's title and abstract seem to be intentionally trying to stir controversy and annoy people, the core issue of FFI unsafety is real. C has many subtle behaviors, and a type system that doesn't describe them well. It also can't express its API's ownership or thread-safety, and there's no true immutability. Correctness of the ABI isn't enforced in any way, so you just smush symbols together and hope for the best. That is ripe for errors, especially when you try to add extra guarantees on the Rust side that C may or may not actually provide.
roarcher 3y ago
"Dressing up Snarky Blog Posts as Academic Papers" Considered Harmful
alecnotthompson 3y ago
The title and subtitle seem completely unrelated. I'm not advocating for rewriting everything but seems like most rewrites won't be using FFI
vpastore 3y ago
[flagged]
Patrickmi 3y ago
I don’t know if they’re stacking these augment up until “the lesser one” gets the front page then Booom
pinkmuffinere 3y ago
Why do we believe this to be from 2017? It has references to SBF being dishonest, which makes me suspicious that it is more recent than that...
nneonneo 3y ago
This is not literally from 2017. It’s a preprint; the 2017 bit in the footer is from the default article template. Per the footer, it’s actually from 2023. You can tell because the abstract mentions SBF and Madoff in the same sentence!
deleted 3y ago
[deleted]
hardwaregeek 3y ago
Wow, this is extremely relevant to my current work (porting from Go to Rust). Adding on to the paper, some other issues are: - Modeling concurrency across boundaries, like if you're p using goroutines but also tokio, how the heck does that work? - Persisting data across FFI, like if you have some Go code that calls Rust, and you want the Rust code to persist stuff in memory, that gets tricky fast. - Assumptions around strings. Go will give you a bag o' bytes and say "it's a string, trust me!" while Rust expects UTF-8. We definitely ran into some of these issues, like remembering who should deallocate which memory.
jmartin2683 3y ago
I’ve rewritten 4 major applications in rust at work. In every case, it turned out to be a fantastic idea.

117 points by libele 3y ago

In the software world, there is no other cancer mass like the mass that constantly recommends anything.

As a hobbyist with only limited C++ and Rust experience, reading things like the abstract of this paper push me towards Rust a bit. The snark is really offputting. As a user of software trying to protect my personal information in an increasingly threatening world, I would like memory safety in more places. From the outside looking in it feels like there are a lot of C and C++ programmers trying to deflect from how poorly their attempts at memory safety have gone and just snarking at the people trying to fix it. I will say that the point about FFI boundaries needing more care is a valid one I had not considered. Is there a name for people who don't work in C++ and never, ever hear "rewrite it in Rust" except from programmers who seem like they're a bit hurt that their language has a competitor?

lesuorac 3y ago
The other part I find amusing is that the issues found in the paper is that not enough was rewritten into Rust!! The first F in FFI [1] means that you have an interaction of non-Rust and Rust. (Or two non-Rust languages but that's moot). [1]: https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface
- cogman10 3y ago
  Yeah, it's a bit like saying "See, Java isn't memory safe! Look what happens when we expose native methods and calls between the JVM and C!" FFI is inherently unsafe regardless of language.
JohnFen 3y ago
> their language has a competitor? I take issue with the notion that languages can have competitors. Languages are tools, and some languages are more suited to some tasks than others, but each has their place. Saying languages compete with each other is a bit like saying different kinds of hammers compete with each other. They don't, each is just optimized for a different kind of hammering.
- nindalf 3y ago
  Thinking of languages as hammers or screwdrivers is too simplistic. Instead, think of languages as platforms. Your productivity in any language is directly proportional to your time and effort investment in it. It's in your best interests to pick the language that's likely to thrive and spend time learning its ins and outs. On the flip side, betting on a horse that doesn't win could mean the loss of months or years of effort. This is why people evangelize the platforms they're invested in - convincing other people to join improves the health of the platform, increasing their return on investment. More adoption => more libraries => more projects => more jobs => more adoption. A virtuous cycle. This evangelizing can sometimes become contentious if others perceive it as an attack on their platform. People defend their language mostly because they don't want to see it lose popularity. If it did, their language's viability is threatened and their investment is in jeopardy. It's also partly because they've spent so working with this language that it's become a part of their identity. A critique of the tool is perceived as an attack on the person.
  - JohnFen 3y ago
    I suppose my views are skewed because I have become competent or better in a large number of languages. I have my favorite general-purpose language, of course (it's C++-as-a-better-C), but I view choosing a language for a particular project to be an engineering decision that I make according to the demands of the project, not based on what language I personally enjoy the most. Developers do get emotionally invested in their tools, and I've seen an uncountable number of holy wars because of that. But all of them strike me as being ludicrous. If another dev uses a language I would not have chosen, that's not a personal affront to me. I assume they made an engineering decision that made sense for their situation. It's all good. > If it did, their language's viability is threatened and their investment is in jeopardy. I sorta see this, but in my experience, it's very easy to overstate this case. If a language is viable enough to develop in initially, it's viable. How popular it is or becomes isn't really that important except in terms of being a business decision ("is it possible to hire people in the future who know this language?")
__s 3y ago
There isn't a name for you, but what you're experiencing is strawman attacks Like the strawman argument where it creates a flawed argument to declare victory over, the strawman attack picks out the most extreme case to declare victory over You'll see this done on left/right political debates where instead of recognizing that most people can find agreeable common ground on 80% of issues, extreme advocates will pick out the opposing extreme advocates to vilify each others' groups I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass
- carlmr 3y ago
  >I think a lot of Rust programmers appreciate where C is the right tool, & a lot of C programmers can admit that memory errors are a pain in the ass That's true, however IME C++ programmers are the most in denial. And yes, RAII has helped a lot. But still we see way too many memory errors coming from C++ code bases.
- avgcorrection 3y ago
  Arguing isn’t a game of diplomacy and middle grounds.
- uecker 3y ago
  A a C programmer, I think Rust got memory correctness right. Unfortunately, I do not like the rest of the language ;-(
prpl 3y ago
it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs - and are probably directly protecting an order or two magnitude more of your personal data than Rust and C++ - even without discussing relatively safe languages (interpreted but with various implementations) like Python, PHP, and Ruby.
- nordsieck 3y ago
  > it’s important to note that memory safety is only one kind of bug. Plenty of go and java programs are memory safe with a litany of bugs While that's true, memory safety bugs are particularly dangerous from a security perspective.
- kimixa 3y ago
  In my experience a memory error is often the result of a logic bug - that is the "first failure" of an existing issue in C++ is a memory error, but the originating logic error still exists and would just cause a different issue under "memory safe" languages. It would still be a bug, and may cause security issues. IMHO the big advantage here is not languages that are memory safe, so much as catch many of those misunderstandings at compile time, or runtime in a better way than "Crash" or worse - silent corruption (Much of this is available for c++ in static analysis and sanitizers and other runtime checks, but them being non-default options seems to make them oddly ignored). I feel them being non-default also means there isn't the same focus on performance - and it's an everything-debug-and-slow-as-hell with a UX purely designed around the dev debugging their own code, or no-checking-at-all-no-brakes rather than in between. The classic "memory errors" that are purely local and just not checking the bounds of an array or similar have been pretty much eliminated if you actually use the features (containers, iterators etc.) of the c++ standard library.
  - Verdex 3y ago
    The problem with memory unsafe languages isn't that they can crash. It's that they won't crash. And instead allow an attacker to load up malicious code into the application.
pkulak 3y ago
"Rewrite it in Rust" is another class of "I use Arch, BTW"; one of those phrases no one has ever actually heard unironically, and that is only used to attack the strawman who supposedly said it.
- hxugufjfjf 3y ago
  Sorry to disappoint, but try searching for that on Github and see the amount of projects where this has been unironically suggested.
marcosdumay 3y ago
Not long ago surgeons didn't have a rule of washing their hands before doing an intrusive surgery, and lots and lots of people died because of that. At a point, one surgeon discovered that, with incontestable proof, and started advocating for hand-washing. When almost all surgeons noticed that something so simple and easy had that much impact, they immediately adopted it and saved a lot of suffering from their patients... Ok, of course they didn't. Almost everybody fought the few wand-washing advocates, tried to shame and discredit them, tried to generate bullshit evidence saying that it didn't help, tried to convince everybody that it didn't matter, all the time denying to themselves that it worked. Surgeons only started washing unanimously their hands when that generation of them retired.
- akprasad 3y ago
  https://en.wikipedia.org/wiki/Ignaz_Semmelweis https://en.wikipedia.org/wiki/Ignaz_Semmelweis > Despite various publications of results where hand-washing reduced mortality to below 2%, Semmelweis's observations conflicted with the established scientific and medical opinions of the time and his ideas were rejected by the medical community. He could offer no theoretical explanation for his findings of reduced mortality due to hand-washing, and some doctors were offended at the suggestion that they should wash their hands and mocked him for it. In 1865, the increasingly outspoken Semmelweis allegedly suffered a nervous breakdown and was committed to an asylum by his colleagues. [...] His findings earned widespread acceptance only years after his death, when Louis Pasteur confirmed the germ theory, giving Semmelweis' observations a theoretical explanation, and Joseph Lister, acting on Pasteur's research, practised and operated using hygienic methods, with great success.
- fasterik 3y ago
  This analogy seems pretty disingenuous. Static memory safety isn't an unambiguous good like handwashing; it has tradeoffs. There are many projects where control over memory is critically important and using a language like Rust is a non-starter. Also, the implication that developers who don't switch to Rust are negligently harming people is unnecessarily moralistic and divisive.
  - 3y ago
vpastore 3y ago
it look like you can use this. https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s https://www.youtube.com/watch?v=cWSh4ZxAr7E&t=1578s This talk is what convinced me to move to Rust definitely. The audience is the perfect representation of the C++ community.
lohnjemon 3y ago
How does memory safety allow you to protect your personal information? How many binary exploits have actually lead to the exposing your personal information? I can count with my fingertips exactly zero times that has happened to me. The times my personal information was compromised happened to me is when I downloaded malicious software. Malicious software doesn't care whether your process has "memory safety", it'll extract anything from the processes memory it wishes. Sure memory safety would at least rule out simple binary exploits, but to be targeted by one is not exactly common. I don't get the narrative of an ever increasingly threatening world. If anything things have only been getting better, at least for the individual users. I remember individuals getting pwned very frequently in the old days. Now, not so much, with DEP, ASLR, and stack canaries. The attacks on businesses have increased, but those attacks are mostly just phishing or otherwise human error related. Attack vectors for actual PI retrieval rarely incorporate some obscure memory bug in a program allowing RCE or remote access. Unless you're a high value target.
- insanitybit 3y ago
  > How many binary exploits have actually lead to the exposing your personal information? It happens with some frequency. WhatsApp was exploited due to a memory safety vulnerability, for example. Chrome 0days for memory unsafe vulns are definitely exploited in the wild. Typically companies have much much larger attack surface, so a technique like phishing is going to be far cheaper to execute. But even still, I've seen a memory safety vulnerability used in an attack against a company. The thing is that most companies' attack surface isn't in C/C++ because... that would suck, so they don't do it. Or if they do they use a specific codebase that's been heavily invested in over decades and they sandbox and isolate the services. So on the one hand, yes, most attacks on companies are not due to memory safety issues but that's in part because of the investments into memory safety. > I remember individuals getting pwned very frequently in the old days. Yep, significant efforts were made to make the internet a safer place. Primarily the sandboxing and disabling of third party plugins in browsers. But this doesn't really matter. Yes, there are other issues like phishing and those are being addressed with other techniques. There are issues like sql injection and those are also being addressed. That doesn't mean that memory safety isn't an issue.

kstenerud 3y ago

OMG please, enough with the "X considered harmful". It just makes me not want to even look at it.

RealityVoid 3y ago
Considered harmful articles considered harmful.
faitswulff 3y ago
I present to you “Considered Harmful” Essays Considered Harmful: https://meyerweb.com/eric/comment/chech.html https://meyerweb.com/eric/comment/chech.html
codelikeawolf 3y ago
Preach! It's only a matter of time before "Considering 'Considered Harmful' harmful considered harmful" shows up.

serverholic 3y ago

I really don’t understand the people who have a problem with rust. Do you not value the increased memory safety? Now that Microsoft and Google are adopting rust and reporting significant decreases in memory related bugs it’s pretty clear that rust does make a difference.

maleldil 3y ago
Rust restricts what you can do when it can't reason about your code. Some developers don't like those restrictions and feel like they're "fighting the borrow checker". Others don't think it's worth it and go back to managed languages. It's usually something like "I don't need the compiler holding my hand, I know what I'm doing", or "I'll just write in Go/Java/etc. so I don't have to worry about memory".
signaturefish 3y ago
TBH, I don't have a problem with Rust so much as I have/had a problem with a section of the rust community. The shouting fanbeings of rust put me off looking into it for years, because when I kept getting "rewrite it in rust!" as the answer to "there's a problem with $THIS_CODE" when talking with colleagues, _even when those colleagues had minimal rust experience_, all I could conclude was that the whole thing was an empty promise and that no-one knew how to solve the problem, but everyone "knew" that the New Cool Language was the way to fix everything. Generalisation from incomplete data - no doubt there was a sensible majority in the rust community, but the fanbeings were _loud_. FWIW I was wrong: I'm getting into rust now and I like what I see, and the discussions around it online and with colleagues are pretty sensible. But, it's taken a while to get there and when you've been in tech for a couple of decades you see this hype cycle and get jaded to it. Erlang is the new hotness ... OCaml is the new hotness ... Java is the new hotness, rewrite everything in Java, wait C# is the new hotness... I suspect rust is here to stay, and I'm gonna learn more about it, and I regret some of my past words about it. But my problem was never with the increased memory safety, or the language at all, pretty much, just the early community. TL;DR: Other humans are the worst, bug reported, fix unlikely :)
- pdimitar 3y ago

nindalf 3y ago

There's a certain tendency to take anything written in a double column PDF followed by a long list of citations as gospel. Maybe that's what the authors were hoping for? The poor quality of writing, contrived examples and unnecessary snark could be why the authors didn't to put their name to this paper.

Verdex 3y ago

Ah yes, the "* Considered Harmful" tradition in computer science. A tradition so widespread that it has even wrapped around upon itself and yielded the "'Considered harmful' considered harmful" paper. Not the best start already. Hmm, written by 'Anonymous Authors'. So is this supposed to be a joke? Is the implication that speaking out against rust makes you the target of unjust persecution? Is it written by people known to have an axe to grind? Abstract: This is a free-verse poem setting up a rust advocate strawman. Do such people exist on the internet? Yes. But time cube also exists on the internet. Introduction: Incrementally rewriting a C/C++ system in rust is bad because FFI can have problems. Which can be simplified with a different spin to be, "C/C++ are so bad that they contaminate even the mighty rust." It feels like the paper might have some good information that would be useful to people who want to augment their codebases with rust. However, it starts off so combative, that I don't think I could seriously recommend anyone actually read it. Maybe just skip the abstract and intro and see what you get out of it?

remexre 3y ago
"Anonymous Authors" is typical for a pre-print that might be sent out for blind peer review.
- vngzs 3y ago
  The only publication that might take this paper without changes is POC||GTFO. Did you read the abstract?
- Verdex 3y ago
  Interesting, TIL. Follow up question then: Is it normal for pre-prints that go out for blind peer reviews to be publicly posted like this? Should I be interpreting this as a leak of some sort, someone trying to get their work public eyeballs without messing with the peer review, etc? Or is this just par for the course in academia?
spoiler 3y ago
> Which can be simplified with a different spin to be, "C/C++ are so bad that they contaminate even the mighty rust." I've written C and C++ for a long time, and... Alas, you're not completely wrong lol. At work there's a still unresolved ticket of me trying to get cross compilation working, and it's basically impossible because of the way most C/C++ tooling is built and works. CLang kinda works nicer here than GCC, but there were other issues with that that I encountered. Basically, it's nearly unsolvable due to the number of hoops one needs to jump to properly link against a dynamic library produced for the target platform (if the host platform is different).

ericseppanen 3y ago

"we model a scenario where the original code is memory-safe; the ported code is memory-safe; and we consider memory safety and undefined behavior that may arise across the FFI layer between the two pieces of code." I may be stating the obvious, but that's a bit of a strawman. Yes, writing good FFI code is hard; yes it could result in security/soundness issues; yes, we could use better tools in this space. But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards, even accounting for the potential problems at the FFI boundary. If I could remove tens of thousands of lines of hard-to-analyze C code, and replace it with tens of thousands of lines of safe Rust, paired with a few hundred lines of hard-to-analyze FFI adapters, that sounds like a pretty good tradeoff to me. I now know exactly where to focus my attention, and I can have confidence that the situation will only improve with time: better tooling may allow me to improve the dangerous FFI layer, and in the meantime I can recklessly improve the safe Rust module without fear of introducing new memory unsafety bugs, unsound behavior, or data races.

JodieBenitez 3y ago
> But nobody rewrites C code in Rust if they believe existing codebase is free of memory safety hazards; they rewrite it because they think the result will contain fewer hazards What if someone makes a strawman out of memory problems so they can rewrite it in Rust ?
- awestroke 3y ago
  Great, let them do whatever they want
Szpadel 3y ago
agree, i wanted to just add that this paper might be right for projects that are not actively developed anymore something like bash or coreutils etc, as there this is fairly well tested code and there aren't that many added features that could introduce issues. for anything that is actively developed it's a whole other story, even if you are confident that the current codebase is safe, each added feature has a risk that it breaks some unwritten contract somewhere and introduces security issues. eg. look at recent vulnerability in sudo, at and second sight it was safe and secure, triggering it required unobvious corner case. how many of similar issues you could have in your codebase that could be dormant for years?

duped 3y ago

The authors don't seem to understand memory safety or FFI and wrote a contrived article about it. Hell, the first example isn't equivalent code. You can't share references across an FFI boundary with C.

woodruffw 3y ago

I'm possibly misunderstanding, but their first example doesn't make sense to me: 1. C can make aggressive aliasing optimizations based on observable behavior, meaning that the compiler may or may not optimize `add_twice` based on the results of any alias analysis it chooses to do. In other words: the author's assumption that a C compiler won't optimize `add_twice` in the same way that Rust will is not a guarantee, and assuming that it won't is relying on unspecified behavior. 2. The author claims that the result of the optimization can result in memory unsafety, and it's not immediately clear to me that that's true: it might be true in an interprocedural sense due to another function's assumptions about how `add_twice` affects its parameters, but this is the same incorrect assumption as in (1). In that sense, Rust is not really involved at all here.

pornel 3y ago
In Rust mutable references are exclusive. They're statically guaranteed to never alias with any other pointer. However, when you call such function from C, the C compiler has no clue about exclusive references, so obviously it can't enforce their invariants. The C side can provide aliased pointers and break Rust's assumptions. The Rust side assumes it's called correctly, and the C side can't know what is correct.
- woodruffw 3y ago
  Right, but that's not controversial, is it? If you call into Rust from C, you need to preserve Rust's invariants; Rust can't preserve them for you.
  - pornel 3y ago
    I don't think anybody expects incorrect code to behave correctly, but as usual the issue is about mistakes. The C compiler can't help you preserve Rust's invariants, so when you make wrong assumptions or declare a wrong interface, instead of a compilation error, you can get UB silently creeping in. The FFI-glue language they propose is meant to prevent these types of mistakes.
3y ago

holmesworcester 3y ago

A lot of the commenters don't seem to understand the thrust of this paper. First, the use of "considered harmful" here is tongue-in-cheek or at least self-aware. Second, the point of the paper is not to say that rewriting in Rust is bad, but to propose a safer approach to incremental rewrites that addresses (what the authors argue is) the risk of introducing new bugs at the C/Rust boundary.

genr8 3y ago

now here we have "X considered harmful" - a common Trope. This seems more like a "First!" to title their paper this, as a meme of the whitepaper meta, that title came first, then the arguments came. I say this because I joked about a paper being released with this name about a week ago and now here it is, but Its a bit lower quality than expected. We might need another one later...

dcsommer 3y ago

There's plenty of good content in this paper. FFI safety is a very important topic, and there are unique concerns with Rust FFI. Such a shame it devolves into unprofessional and inflammatory remarks. The authors could have put their names on the paper and gotten a decent credit if they could have kept their emotional responses to the topic out of it.

cogman10 3y ago
The problem I have with this article is it's pointing at a universal problem (FFI safety) and narrowing that to a rust problem. Yes, FFI is dangerous, that's true regardless of language (including C). FFI is inherently platform, language, and even compiler specific. It's super tricky to get right.

lucideer 3y ago

> Anonymous Authors Because no-one would want to put their name to this. There may be some valid arguments in there (though it seems to be just "FFI is hard ergo noone should never attempt phased migration of any system codebase"), but even content aside, the tone is that of a moody teenager. The abstract in particular is one of the worst things I've ever read - the introduction doesn't read fantastically eitherr.

alex_lav 3y ago

"Rewrite it in ____" should pretty much always be a last restort. Rewriting takes a ton of time and effort, has its own downsides, and just generally doesn't have as obvious a value add to customers/consumers (outside of pretty specific scenarios) to justify the cost. Plus, rewriting anything in anything else just invites a whole new suite of problems with the new thing that probably/definitely weren't accounted for. Now, for personal software I say hell yes. If a person is writing code for the fun of it, or simply wants to learn about concepts, rewrite whatever in whatever and have a great time. That's the point! But for professional/commercial software, rewriting is probably more expensive than is realized.

dmkolobov 3y ago

I think some folks are misreading the authors intentions(possibly due to aforementioned snark): they’re not advocating for sticking to existing C codebases over rust. They identify FFI as an area where it is easy to make mistakes which lead to undefined behavior, argue that it is the result of competing assumptions between C and rust, and then propose a formal system implemented in both in C and in Rust to resolve those issues. Sure, the problems they identify wouldn’t exist if everything was rewritten in Rust, but on a large enough / old enough codebase, that may impossible to do all at once. This paper attempts to find a way to make rust better within those organizational constraints. The audience here is not engineering managers deciding in your next tech stack, but programming language researchers.

Verdex 3y ago
> I think some folks are misreading the authors intentions(possibly due to aforementioned snark) Yes. It looks like the paper has some useful things to say. However, that abstract + intro is like walking into a wedding and splashing red paint on the bride and then announcing a bunch of very good reasons why the wedding should not continue. Nobody is going to be listening. Perhaps another way to say it is that nobody is misreading their intension. What they're doing is ignoring reasonable concerns said in an unreasonable way.
- dmkolobov 3y ago
  I’m not a fan of “being cute” in papers typically, for the reason that it detracts from the central ideas. Clearly this happened here. These discussions frequently feel “tense”, wherein criticisms based on specific technical details are tied to an attack on the language as a whole. In that context, the authors definitely shot themselves in the foot with the opening/title.
- soqb 3y ago
  it seems under this view, the conclusion that can be drawn for the paper is “replacing parts of a C codebase with the conceptually equivalent Rust code without any thought as to the nuances of Rust ffi may lead to bugs if the C code is already contrived” which doesn’t seem too useful a conclusion to me.

pornel 3y ago

Although the paper's title and abstract seem to be intentionally trying to stir controversy and annoy people, the core issue of FFI unsafety is real. C has many subtle behaviors, and a type system that doesn't describe them well. It also can't express its API's ownership or thread-safety, and there's no true immutability. Correctness of the ABI isn't enforced in any way, so you just smush symbols together and hope for the best. That is ripe for errors, especially when you try to add extra guarantees on the Rust side that C may or may not actually provide.

roarcher 3y ago

"Dressing up Snarky Blog Posts as Academic Papers" Considered Harmful

alecnotthompson 3y ago

The title and subtitle seem completely unrelated. I'm not advocating for rewriting everything but seems like most rewrites won't be using FFI

vpastore 3y ago

[flagged]

Patrickmi 3y ago

I don’t know if they’re stacking these augment up until “the lesser one” gets the front page then Booom

pinkmuffinere 3y ago

Why do we believe this to be from 2017? It has references to SBF being dishonest, which makes me suspicious that it is more recent than that...

nneonneo 3y ago

This is not literally from 2017. It’s a preprint; the 2017 bit in the footer is from the default article template. Per the footer, it’s actually from 2023. You can tell because the abstract mentions SBF and Madoff in the same sentence!

deleted 3y ago

[deleted]

hardwaregeek 3y ago

Wow, this is extremely relevant to my current work (porting from Go to Rust). Adding on to the paper, some other issues are: - Modeling concurrency across boundaries, like if you're p using goroutines but also tokio, how the heck does that work? - Persisting data across FFI, like if you have some Go code that calls Rust, and you want the Rust code to persist stuff in memory, that gets tricky fast. - Assumptions around strings. Go will give you a bag o' bytes and say "it's a string, trust me!" while Rust expects UTF-8. We definitely ran into some of these issues, like remembering who should deallocate which memory.

jmartin2683 3y ago

I’ve rewritten 4 major applications in rust at work. In every case, it turned out to be a fantastic idea.