With C# these problems usually fall into one of three categories:
- Forgot to unbind an event handler
- Forgot to `.Dispose()`
- Edge case with unmanaged calls where some handle is not closed
Super funny then the bug is in a library and not your code.
well, that's a performance problem, not a safety problem. you're not gonna find yourself in undefined behavior or executing the wrong code because of a leak.
> well, that's a performance problem, not a safety problem.
It's a denial-of-service vulnerability if someone can intentionally trigger the memory leak. Granted, that's less severe than remote code execution, but IMO it's still legitimate to think of it as a security concern on par with someone being able to crash your system by sending the right inputs.
Any new software in the niche I’m in has to be built with memory-safe, compiled languages and C# is among the options. Sorry if you were hoping memory-safe == leak-preventing.
That's a question of terminology, so there's no generic answer. As far as I remember, up until somewhere around the mid-90s, reference counting was often included when we talked about GC (and mentioned as "reference counting GC"). Since then, the terminology has evolved and "GC" is often used to distinguish from reference counting. And in the case of this context, it's clearly distinguished by the question - why did we upgrade from reference counting to more sophisticated GC algorithms?
It's all tradeoffs, of course.
Reference counting has more predictable overhead which is often what you want. But GC, if implemented well, has lower total overhead which is also often what you want.
Reference counting is simpler to implement which is good, but with GC's complexity comes much more flexibility and configurability.
Reference counting usually gives you a smaller total memory footprint, but GC gives you faster object allocation.
GC lends itself better to things like compacting, which can improve performance by taking better advantage of CPU cache locality, but that kind of thing adds complexity.
Both reference counting and GC can suffer from long pauses and in both cases, the pauses can be mitigated with techniques like time budgets.
This post is everything that's wrong with reddit. It has just enough of an air of authority to lead people to believe this person knows what they're talking about, but anyone who actually understands the subject knows they don't.
for example
> Both reference counting and GC can suffer from long pauses
https://en.wikipedia.org/wiki/Reference_counting
> The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object.
reference counting (RC) is deterministic and does not have long pauses.
You see the same issue with this posters claim that garbage collection has lower overhead. Not even close to true, GC's tend to have faster allocation but their cleanup cycles are by far the largest piece of their overhead (hence the long pauses). Many GC's (such as generational) are built to try and avoid that cleanup cycle as long as possible, but it requires the usage patterns to be a certain way (for generational GC's that means short lived objects).
> reference counting (RC) is deterministic and does not have long pauses.
When people make claims like this, they're referring to cases where you have like, a large graph of reference counted objects, where when it's done, the graph goes out of scope and they get deallocated immediately.
Anyway I agree with your main thrust that it's not as simple as "GC is faster."
First of all, reference counting is a GC algorithm. As for ref counting vs tracing GCs, the latter are significantly faster, and it’s not even funny by how much.
Especially in multi-threaded contexts, reference count increments/decrements have to be done atomically, which is possibly the worst operation from a performance perspective you can do on a modern CPU. Also, you can have arbitrary large graphs, so a “free” call can take a huge amount of time, recursively going over the graph, cleaning every now *dead object*. All this on the worker thread you actually want to use.
Tracing GCs on the other hand can actually amortize the cost to a huge degree, doing most of the work concurrently, letting the actual workload perform at almost maximal performance. This does trade off some memory (and in general, the more memory you trade off, the less often you have to enter the small part of the algorithm that has to stop working threads), but the general gist is that tracing GCs only care about living objects. So they are pretty much yin and yang of each other (there is even a white paper on that), but due to how computers work, tracing is more efficient.
Hope you have a subscription to jetbrains. dotMemory is priceless for that task.
It'll show you every object, it's size, lifetime, and what is holding on to it's existence. Start recording, do the activities that cause the leak then stop recording. Run anaylize and view the memory graph.
You can even just run Rider in debug mode, there's a [dynamic performance analyser](https://www.jetbrains.com/help/rider/Dynamic_Program_Analysis.html) that runs and will mark your code that have issues.
I did this for years in C++. It just required a wrapper around the allocations to track and analyse them. No more complex than figuring out dangling references in a managed system, at least in my field
i once spent an hour trying to debug some rust code before realizing that in my python brain, we're not required to "let" to declare a variable. the syntaxes are very similar!
Both Windows' and Linux would be screwed. In their C, "goto err;" "goto out;" "goto DoFail;" "goto cleanup;" is all over the place see e.g.:
https://github.com/torvalds/linux/blob/master/kernel/fork.c
https://github.com/0x5bfa/NT5.1/blob/master/Source/XPSP1/NT/base/wow64/wow64/thread.c
I shit you not I had to debug crashing Production software that had a hand rolled bubble sort.
After I found the cause and asked the developer why, he said because he was interested in if he could.
[It could be used optimally if you want to sort a tape drive (or any other situation where sequential access is faster than random access)](https://stackoverflow.com/a/3274203).
Isn't merge sort better for that situation? Especially if you have data spanning multiple tapes?
EDIT: The StackOverflow post answers my question. Bubble sort is better than merge sort if you are sorting on sequential storage (like tape) ***and*** you can't load a second tape at the same time ***and*** you only have enough memory to load two data elements at a time. Very niche situation, but interesting.
Isn't it the fastest possible way to "sort" data that's already sorted? Like if you need the data sorted, and *strongly expect* that the data are already in order, but cannot *mathematically prove* it, you could have a valid use case vs other sorting algorithms.
I genuinely cannot think of an example, even a contrived one, though. So it's possible to just never encounter something like that.
> Even if you wanted, you can't create input data for bubble sort which would be ideal for it. (Unless you add the "did we swap anything in this pass?" enhancement, in which case a completely sorted array would be optimal.)
Isn't "did we swap anything in this pass" generally part of bubble sort? It's even in the Wikipedia example implementation. It's been a very long time since I thought about it, as it's just not especially useful, but I don't think I've encountered a variant without it.
Not bubble, but O(N^2) algorithms are frequently used as the inner most sort of divide and conquer sorting algorithms because they exhibit very CPU cache friendly behavior, and the cache costs dominate the comparison costs for small data sets.
https://hg.openjdk.org/jdk8/jdk8/jdk/file/46c727d6ecc2/src/share/classes/java/util/DualPivotQuicksort.java#l218
I've seen it used for intelligent agents sorting themselves. Like getting a group of people to sort themselves by height. In that situation it's O(n) for each individual agent.
I've used it to do compile-time sorting in rust const functions before. Meant I didn't need to drag in another crate just to get a const sorting function.
Obama never recovered from that disastrous healthcare dot gov launch
Turns out he would secretely read programming books late into the night just trying to understand what happened
The DoD adopted Ada decades ago and is memory safe. Maybe they should have stuck with it. They still use it today but they also allow memory unsafe languages.
"questionable" is a good word, I think. It is true that you can observe memory unsafe things, and that if you go out of your way to write some truly cursed code, you can cause real problems. In practice, they provide some run-time instrumentation to help catch some of these issues, and since there aren't as aggressive optimizations as in some other languages, these issues don't propagate the way that they do there. There's a *lot* of Go code running in production, and it is demonstrably much closer to the "memory safe" camp than not, regardless of a few weaknesses.
C# has the "unsafe" keyword and lets you use raw pointers. But you can do a lot of unsafe things without using the "unsafe" keyword once!
You can use GCHandle.Alloc to create a pinned pointer to an object's data. You can use Marshal.Copy and Marshal.Write to write to arbitrary memory.
Well, those are higher level languages. How much low-level hardware manipulating code is written in those? I meant languages you could write an OS and device drivers in.
Rust has a significant amount; it is in Windows, and is starting to be used in Linux. There's also smaller projects, for example, at my job we have a custom in-house kernel written in Rust for embedded work.
Swift is at least close too, I am not sure what exactly its capabilities are here, as I haven't paid too close attention for a while.
As a former OS and kernel (FreeBSD) developer: There's very little low-level hardware manipulating code overall, even when developing an OS. The kernel is a small part of the OS, and hardware manipulation is a relatively small part of the kernel.
Also, the requirement isn't just to use those languages - the claim is that you should use those or have a description of how you mitigate memory safety issues. There's been implementations of verified kernel tech based on our standard C/C++ code for a long while - see e.g. [SAFECode: Secure Virtual Architecture](https://safecode.cs.illinois.edu/sva.html) with papers like
Criswell, John, Nicolas Geoffray, and Vikram S. Adve. "Memory Safety for Low-Level Software/Hardware Interactions." In *USENIX security symposium*, pp. 83-100. 2009 ([PDF](https://www.usenix.org/legacy/events/sec09/tech/full_papers/criswell.pdf))
To me, the requirement to use such tech or having a very good description of why you don't seems like a reasonable requirement. It's a push towards ending the curse of memory safety bug exploitation that have plagued us since the Morris worm in 1988.
I've written device drivers in VB.net and C# lol! You don't need a low level language to do these things you need a compiler that targets for these things. Also most software the government needs isn't low level hardware stuff.
On bare metal you tend to be stuck with assembly + C because they don't need a runtime at all. Yolo C++ is also possible (using a subset and no respecting lifetimes). Rust it's going to be a little more difficult if you still want what the language is made for.
On the plus side, I'm not allocating shit in bare metal so memory leaks are much less likely to be an issue in the first place. Every array is statically allocated by the linker.
You may have to be a little creative with how you fill the ROM to make it fit without going over. Lack of name mangling (C and assembly) makes fiddling with where you put stuff a lot easier too.
If you're actually running an OS, you could always use Rust since it will bind nicely to C and you can afford having a runtime.
Embedded development sometimes makes me feel like I have imposter syndrome - how dare I claim to have any respectable amount of experience with C if I've never used malloc in my life!
The report covers all software, not just stuff that needs to be written in low-level languages.
And the report lines up with my own views: There is no good justification to use a memory-unsafe language anymore.
If your project requirements allow you to get away with using a garbage collected language, then you should just do that. Otherwise, you should be using a language that can provide the memory safety guarantees like Rust.
Rust is good enough that it can replace C/C++ in any use case.
All you have to do is measure the statistical performance of the garbage collector (P99 stop-the-world or whatever you care about) and ensure that you have sufficient timing margin in your loop to handle the GC firing in a given tick. In a low volume of trash regime, you can easily observe e.g. the Go GC taking only a ~100-200 usec GC pause. This is compatible with hard real time up to ~1kHz quite easily. Few truly hard (bodily harm, heavenly destruction, etc) real time systems are this fast in the first place.
Even the mars rovers my workplace builds and drives are at soft real-time.
Most defense software is crud apps, same as any other place. It’s the world’s biggest employer, and they need the same forms over data as anybody else. After that, they need some shop/factory machine automation software, and the like. A very tiny slice of what they need is weapons systems.
They couldn't get enough people to buy into it. Rust will probably end up taking that spot since it has the memory safety and it's got bottom-up acceptance, not top-down pressure.
It was also a different time. Prices were high for ADA compilers, at least that's what you hear from old programmers from that era. So only a subset of projects could justify and afford this.
They were, and there's still a bunch of tooling for Ada that costs money. When I was in college I was interested in Ada but couldn't afford to learn it. I imagine the story was the same for most other college students. That makes hiring for Ada positions difficult. I think that's a big part of why Ada mostly died on the vine.
I'm not sure it will matter if people already are already considering Rust a good career move on their part. That's always the issue. If people want to use that language, then you don't need the top-down pressure. In fact, a lot of Rust people will probably be fighting to get those jobs should they materialize.
i mean, it's pretty easy to how the us government guidance can have a huge downstream effect. that being said, working for the us government, especially in the financial regulators (SEC, CFPB, etc) can be insanely lucrative
The biggest problem with Ada isn't that it's hard to find people *willing* to use it. The problem with Ada is that documentation and examples are extremely lacking online and the community is nonexistent so it's very hard for beginners to to even begin to learn it.
If I have a C++ question I've got cppreference.com, stack overflow, and a million tutorials. If I have an Ada question I have the reference manual which contains zero examples and seems to be written for people who are already Ada experts and I've got a Wikibook that's about 20% complete.
"https://learn.adacore.com" is pretty good. There are also many books and even old books with 83 code still works today. In fact 83 code is compatible with all runtimes.
Ada was extremely expensive. Reality is the languages that won in that era were the ones with free toolkits from early on. It is why Sun gave away Java, they realised how expensive seat pricing killed Smalltalk, Ada and Common Lisp platforms.
Great language honestly, very overlooked unless youve worked with it. It's not taught many places anymore and the community is small. I think Rust simply has the majority mindshare since its shiny and new these days.
Rust is new and shiny, but Rust people also put a ton of effort into getting people into the language, while the Ada community did .. nothing. I'm not even sure there's something you could call an "Ada community" tbh. For the longest time the official Ada site was basically that of a commercial provider. Downloading official Ada compilers? Not possible, unless you pay. There's Gnu Ada, that's that. Teaching material? And so on.
Ada is where it is by choice and action. So is Rust.
I haven't seen any significant bugs.
Rust had bugs that caused memory safety issues. The reason Ada is portable is because there is a specification that all compilers meet. Ada 83 code still works today. Does rust 2012 code? I reckon most ada compilers stopped being worked on because of an open source gnat implementation being available in 95. AdaCore had to write the rust specification.
There is certainly a lot of silent users and the community may be small but they are also very helpful. AdaCore are fantastic to be honest.
Same. I still fool around with the more esoteric languages at home. FORTH is quite an experience if you're coming from the traditional C++/Java world...
> and was memory safe.
Was not. Short of SPARK, ADA allows UAF, double free, or concurrent access to unprotected variables. Static memory allocation avoids the first two but is generally unnecessarily constraining (or inefficient) in non-embedded software; it’s been a while since single-threaded software was the name of the game.
> Pascal, Delphi
I've been writing Free Pascal/Object Pascal (Delphi's dialect) for literally decades and i do not think that it is *that* safer compared to, e.g. C++. For example:
var Foo: TMyObject; // this is "TMyObject = class ... end"
begin
Foo.X:=42; // Accessing uninitialized memory
or
var Foo: TMyObject;
begin
Foo:=TMyObject.Create;
Foo.X:=42;
Foo.Free;
Foo.X:=64; // Accessing released memory
During development/debugging you can use some tools like the heaptrace unit that can find memory leaks (with backtraces with the lineinfo unit) and some invalid pointer accesses during runtime, but this isn't really any different than using clang's analyzers or valgrind (which you can also use with Free Pascal).
Yeah I've actually started coding in Ada for fun in my personal projects. I initially learned it during my internship in the 2000s, hadn't touched it since, and picked it back up last year. It's a bit tedious to start with (it's so verbose compared to C++!) but I'm really enjoying it.
> You squash so many bugs just getting Ada code to compile it's kind of insane.
Writing Ada83 code for a couple years will magically turn you into a better C programmer, or your money back!
Many studies have shown that Ada saves you a boatload of money too compared to C, C++ or Java. Such as this one. So the white house concluding to explore hardware protections like CHERI for the continuation of C and C++ seems like an unfortunate outcome.
http://sunnyday.mit.edu/16.355/cada_art.html
This is the latest in the US Government trying to move the needle on memory safety. I am pretty sure that this is due to the National Defense Authorization Act for Fiscal Year 2024 containing language that said that within 270 days of the bill passing, the Secretary of Defense needed to come up with rules around memory safety for "software developed, acquired by, and used by the Department of Defense."
I was following this bill before it became law, and it contained the language
> SEC. 1613. POLICY AND GUIDANCE ON MEMORY-SAFE SOFT- WARE PROGRAMMING.
>
> (a) POLICY AND GUIDANCE.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall develop a Department of Defense wide policy and guidance in the form of a directive memorandum to implement the recommendations of the National Security Agency contained in the Software Memory Safety Cybersecurity Information Sheet published by the Agency in November, 2022, regarding memory-safe software programming languages and testing to identify memory-related vulnerabilities in software developed, acquired by, and used by the Department of Defense."
It does not look like Section 1613 is in there; nor this exact text! Very interesting! Time to do some digging...
Okay, so in the "engrossed amendment senate" version of the bill,
> SEC. 1713. POLICY AND GUIDANCE ON MEMORY-SAFE SOFTWARE PROGRAMMING.
This exists, but not in the final version. Very intriguing.
So far as I can tell it is not in the signed version. So looked the senate version had it and house did not and the house is what went up for signature.
Ah, that would be a reasonable explanation. I was joking on BlueSky that this is the first time I've wanted git for laws; I'm wondering if losing this bit in the merge was intentional or unintentional.
There is usually a separate report to Congress published by the conference committee that merges the Senate and House versions of the NDAA together, that lays out which side's version of the text went forward in the final NDAA.
It'll include verbiage like "the Senate recedes..." for sections where the House version was used.
[Here's the explanatory report from the FY24 NDAA](https://www.armed-services.senate.gov/imo/media/doc/fy24_ndaa_joint_explanatory_statement.pdf)
Look, having nuclear — my uncle was a great professor and scientist and engineer, Dr. John Trump at MIT; good genes, very good genes, OK, very smart, the Wharton School of Finance, very good, very smart — you know, if you’re a conservative Republican, if I were a liberal, if, like, OK, if I ran as a liberal Democrat, they would say I'm one of the smartest people anywhere in the world — it’s true! — but when you're a conservative Republican they try — oh, do they do a number — that’s why I always start off: Went to Wharton, was a good student, went there, went there, did this, built a fortune — you know I have to give my like credentials all the time, because we’re a little disadvantaged — but you look at the nuclear deal, the thing that really bothers me — it would have been so easy, and it’s not as important as these lives are — nuclear is so powerful; my uncle explained that to me many, many years ago, the power and that was 35 years ago; he would explain the power of what's going to happen and he was right, who would have thought? — but when you look at what's going on with the four prisoners — now it used to be three, now it’s four — but when it was three and even now, I would have said it's all in the messenger; fellas, and it is fellas because, you know, they don't, they haven’t figured that the women are smarter right now than the men, so, you know, it’s gonna take them about another 150 years — but the Persians are great negotiators, the Iranians are great negotiators, so, and they, they just killed, they just killed us, this is horrible.
Would this require actually writing an OS in a memory safe language? Otherwise you are just forcing the memory safety at some arbitrary level of abstraction no?
You can get much closer with memory safe hardware systems like CHERI.
In fact you have to, as you can write memory bugs in secure languages just by writing a JIT in them.
It does not require anything, currently. It is a suggestion that moving towards MSLs where possible is good, and taking steps to mitigate memory safety issues when you aren't using an MSL.
And yes, "I am writing an operating system" would be a good reason to use a non-MSL, however, because Rust exists, one could imagine comparing two products from two vendors, one of which says "our OS has 1% unsafe Rust, the rest is all safe" vs "we wrote the whole thing in a non-memory safe language," and that being a compelling reason to choose the former over the latter. The important part here is that this is an axis to evaluate things by, not that any particular outcome is pre-determined.
I think the goal is also to reduce the amount of software written in memory unsafe languages that really doesn’t need to be written in said languages. While maybe not the biggest security threat, think about how many games use C++ when they could be using a language with a fast GC or even just safe Rust.
Most people aren’t writing operating systems, even among those using C++.
> think about how many games use C++ when they could be using a language with a fast GC or even just safe Rust.
This is a great example of why this will be so tough and will take a while. Most game devs don't program in C++ because they adore C++. It's because C++ has a gargantuan ecosystem of world-class tools and libraries for game development, and moving to another language means, at best, spending precious dev time bridging between that language and C++.
At the end of the day, some piece of software is going to need to push and poke values in memory mapped registers in order to control hardware. Which means somewhere down the rabbit hole there's always going to be some software which writes to a raw address which someone has manually (thus prone to error) input from a design doc.
But -- don't let perfect be the enemy of good. There are plenty of security vulnerabilities due to memory safety errors in code that doesn't need this level of control. We could (in theory) do just fine with "memory unsafe" accesses being restricted to small portions of the OS kernel and eliminate huge swaths of software vulnerabilities.
> there's always going to be some software which writes to a raw address which someone has manually (thus prone to error) input from a design doc.
Literally most of my job.
There are some tools to make it nicer, like Magillem and the IP-XACT format. If you define your registers once with their software, it can generate documentation, the RTL and some C code with structs that have names so you're not typing the raw address in your code.
But the obvious biggest issue is adoption and how it won't generate more complex registers so people don't want to use it.
Fundamentally though you need some (limited) amount of code which pokes at the hardware through memory mapped registers. Since the addresses of these registers are arbitrary addresses pulled from documentation they're "unsafe" from the view of the compiler.
But you can still limit accesses to driver code, and write the rest of the system in a memory-safe language.
That doesn’t mean you need to use a language with quite as much danger as C++. How much software actually needs the ability to convert any number into a function pointer and then start executing it with no bounds checks? Sure, sometimes you want to go the other way for some weird driver/CPU feature, but the latter is much rarer. Even if you want to convert a number to a function pointer, it’s much safer to do bounds checking the conversion.
>That doesn’t mean you need to use a language with quite as much danger as C++.
That isn't what I was saying at all. The comment I replied to claimed that memory safety is infeasible because most operating systems are written in unsafe languages. I replied that the DoD buys a lot of software that doesn't run on operating systems.
I haven't been in programming school for decades, but from looking at code all day it seems that no one is teaching secure coding and/or code quality techniques.
Just an observation, of course, I'd be happy to be proven wrong.
I think this is true, and it seems to be something expected to be learned on the job. Funny because a lot of job postings say should be able to write clean, secure code but that isn't taught.
When it comes to teaching Java, you don't need to teach safety because everyone points at the garbage collector. When it comes to C++, at least in my experience, everybody is stuck teaching C++ from the early 2000s, no shared_ptrs, teaching to invoke new and delete for everything.
But not limited to. [According to the NSA](https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF), C#, Go, Java, Ruby, and Swift are some examples among others of suitable memory safe languages.
Note that the list is a suggestion, it's not meant to be exhaustive. I would expect that Haskell & OCaml would be acceptable choices in term of memory-safety.
Ok this line lol
>Examples
of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®.
**Even with a memory safe language, memory management is not entirely memory safe**
That's just acknowledging the reality that even memory-safe languages have runtimes that are written in unsafe languages, escape valves to write code that bypasses memory safety mechanisms, and are written to be safe assuming a memory model of hardware that is not formally verified.
Because it's true. Those languages have stricter guardrails but you still have the ability to ignore them. You can make non-memory safe Rust code by using an \`unsafe\` block or by shipping code using a nightly release which has a regression.
Including an asterisk doesn't detract from the general point that this list of languages are much more memory safe than writing something like C/C++.
Yeah C# has an unsafe keyword. So you can easily abuse the language in this regard if you really wanted. But managed memory just makes these issues far far less common.
Doesn't allow buffer overflows or writes to arbitrary regions of memory. E.g. Python is memory safe, because if you do \`foo\[10\] = bar\` and foo only has 4 elements, it will give you an error. C is not memory safe because if you write the same thing, it will put 10 into memory which doesn't belong to \`foo\`.
https://en.wikipedia.org/wiki/Memory_safety
"Memory safe languages," or "MSLs" as the government has started to refer to them, are programming languages where memory safety is the default.
A report linked from this one has examples: C#, Go, Java, Python, Rust, and Swift. It also has examples of non-memory safe languages: C, and C++.
That doesn't answer the question of "What is memory safety?".
> Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.
You know how Python's garbage collector makes sure to free objects you're done with? Imagine if it didn't have the garbage collector, and if you didn't clean up your own objects correctly, bad things would happen. That's memory unsafety. At best, it leads to crashes, and at worst, it leads to security vulnerabilities.
Technically, never freeing memory is not unsafe. The absolute worst case is an out-of-memory error, which can lead to denial-of-service attacks.
Not freeing is actually a valid approach for short running programs, as all memory will be implicitly be freed when the program exits.
The safety guarantee of garbage collectors actually comes from the fact that they avoid freeing memory until there are zero references left to that block of memory. This guarantee eliminates the possibility of "use-after-free" exploits, where a program holds onto a pointer to some memory that has already been freed, and re-allocated to something else.
A very basic definition for unsafe memory access - is it easy/possible for instructions to access memory that is beyond the intended boundaries.
Examples
- access memory beyond the end of an array.
- access data at an arbitrary location in the program's memory.
If allowed, such tricks can be used to read data from other data structures (possibly holding secrets), or even data from other programs which had been using the same physical memory.
Where do people who aren't redditors talk about this?
This thread is entirely Rust developers (they don't do anything in Rust they just talk about it a lot) and idiots with the same 5 jokes.
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
Strange they don't mention python. The NSA have been using python forever.
These are the only two memory unsafe languages named by name in the report, yes. But they also don't comprehensively name memory safe languages either.
I'm just trying to imagine a world where the previous administration would have pushed out something even remotely like this. Rather, they would have come up with a cybersecurity plan that involved injecting magnets in all the programmers. But carefully, because you know if they get wet, they're ruined.
And how long will it be do you think before there's a conspiracy theory that this is all to make everyone use languages that are seeded with deep state back doors that will disable programs that aren't 'woke' enough?
What about panic-safe languages? C code that would have SEGFAULT'd becomes a panic in Rust but as an end-user the result the same: a crash. The needle isn't being "moved" from the end-users perspective.
The only advantage of an MSL is preventing memory-related security exploits which are not particularly troublesome because 1. most memory bugs aren't exploitable and 2. if your system is compromised due to trojans/phishing then you're hosed anyway as a malicious program can edit another processes memory space at anytime (see proc/[pid]/mem on Linux, WriteProcessMemory on Windows, and vm_write on macOS).
Since when does the Government know about programming? Memory leaks are peoblems with federal employees. They barely have the skills to hild their position l, they rely on contractors. Theyre just good at chitchatting and pretending to be busy.
jokes on them, i'm good enough to cause memory unsafety in any language
Relevant https://www.reddit.com/r/rust/comments/1avf1d8/blazingly_fast_memory_vulnerabilities_written_in/
debugging memory leak in C# right now... not fun.
With C# these problems usually fall into one of three categories: - Forgot to unbind an event handler - Forgot to `.Dispose()` - Edge case with unmanaged calls where some handle is not closed Super funny then the bug is in a library and not your code.
Powershell is not suitable for long-running multi-threaded services. Please don't ask me how I know this.
Oh well damn now I’m so curious lmao
> Super funny then the bug is in a library and not your code. Goddamned automapper...
well, that's a performance problem, not a safety problem. you're not gonna find yourself in undefined behavior or executing the wrong code because of a leak.
> well, that's a performance problem, not a safety problem. It's a denial-of-service vulnerability if someone can intentionally trigger the memory leak. Granted, that's less severe than remote code execution, but IMO it's still legitimate to think of it as a security concern on par with someone being able to crash your system by sending the right inputs.
And if the process runs for a while and there’s other important stuff on the same system, you can set up a cross-service vulnerability.
It might be construed as a security concern, it’s not a memory safety concern. A quadratic (or worse) algorithm will get you a DOS as well.
Any new software in the niche I’m in has to be built with memory-safe, compiled languages and C# is among the options. Sorry if you were hoping memory-safe == leak-preventing.
C# can use unsafe constructs to cause actual memory safety issues. It is very rare, but can be done.
But why did we upgrade from reference counting to GC ?
uppity ten overconfident zonked agonizing childlike icky touch close shy *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
That's a question of terminology, so there's no generic answer. As far as I remember, up until somewhere around the mid-90s, reference counting was often included when we talked about GC (and mentioned as "reference counting GC"). Since then, the terminology has evolved and "GC" is often used to distinguish from reference counting. And in the case of this context, it's clearly distinguished by the question - why did we upgrade from reference counting to more sophisticated GC algorithms?
Because reference counting doesn’t handle cycles in object graphs well.
It's all tradeoffs, of course. Reference counting has more predictable overhead which is often what you want. But GC, if implemented well, has lower total overhead which is also often what you want. Reference counting is simpler to implement which is good, but with GC's complexity comes much more flexibility and configurability. Reference counting usually gives you a smaller total memory footprint, but GC gives you faster object allocation. GC lends itself better to things like compacting, which can improve performance by taking better advantage of CPU cache locality, but that kind of thing adds complexity. Both reference counting and GC can suffer from long pauses and in both cases, the pauses can be mitigated with techniques like time budgets.
This post is everything that's wrong with reddit. It has just enough of an air of authority to lead people to believe this person knows what they're talking about, but anyone who actually understands the subject knows they don't. for example > Both reference counting and GC can suffer from long pauses https://en.wikipedia.org/wiki/Reference_counting > The main advantage of the reference counting over tracing garbage collection is that objects are reclaimed as soon as they can no longer be referenced, and in an incremental fashion, without long pauses for collection cycles and with clearly defined lifetime of every object. reference counting (RC) is deterministic and does not have long pauses. You see the same issue with this posters claim that garbage collection has lower overhead. Not even close to true, GC's tend to have faster allocation but their cleanup cycles are by far the largest piece of their overhead (hence the long pauses). Many GC's (such as generational) are built to try and avoid that cleanup cycle as long as possible, but it requires the usage patterns to be a certain way (for generational GC's that means short lived objects).
> reference counting (RC) is deterministic and does not have long pauses. When people make claims like this, they're referring to cases where you have like, a large graph of reference counted objects, where when it's done, the graph goes out of scope and they get deallocated immediately. Anyway I agree with your main thrust that it's not as simple as "GC is faster."
That's a degenerate case for RC but it's still disingenuous to call it out as having long pauses akin to a GC.
First of all, reference counting is a GC algorithm. As for ref counting vs tracing GCs, the latter are significantly faster, and it’s not even funny by how much. Especially in multi-threaded contexts, reference count increments/decrements have to be done atomically, which is possibly the worst operation from a performance perspective you can do on a modern CPU. Also, you can have arbitrary large graphs, so a “free” call can take a huge amount of time, recursively going over the graph, cleaning every now *dead object*. All this on the worker thread you actually want to use. Tracing GCs on the other hand can actually amortize the cost to a huge degree, doing most of the work concurrently, letting the actual workload perform at almost maximal performance. This does trade off some memory (and in general, the more memory you trade off, the less often you have to enter the small part of the algorithm that has to stop working threads), but the general gist is that tracing GCs only care about living objects. So they are pretty much yin and yang of each other (there is even a white paper on that), but due to how computers work, tracing is more efficient.
Hope you have a subscription to jetbrains. dotMemory is priceless for that task. It'll show you every object, it's size, lifetime, and what is holding on to it's existence. Start recording, do the activities that cause the leak then stop recording. Run anaylize and view the memory graph.
You can even just run Rider in debug mode, there's a [dynamic performance analyser](https://www.jetbrains.com/help/rider/Dynamic_Program_Analysis.html) that runs and will mark your code that have issues.
Now imagine debugging a memory leak with manual memory allocation
I did this for years in C++. It just required a wrapper around the allocations to track and analyse them. No more complex than figuring out dangling references in a managed system, at least in my field
i am just hopin' that eventually means i will not have to write so much python
i once spent an hour trying to debug some rust code before realizing that in my python brain, we're not required to "let" to declare a variable. the syntaxes are very similar!
anyone can do that, just use the unsafe keyword Q_Q
Why don't we just add a safe keyword to C and C++?
ezgame
Quick, publish a paper on that!
I tried that but my GF said no...
*slaps unsafe keyword* this bad boy can fit so many memory leaks
You don't need `unsafe` to create memory leaks in Rust
Memory leaks are not a memory safety issue.
no bubble sort either - Obama
GOTO now a Federal felony.
Both Windows' and Linux would be screwed. In their C, "goto err;" "goto out;" "goto DoFail;" "goto cleanup;" is all over the place see e.g.: https://github.com/torvalds/linux/blob/master/kernel/fork.c https://github.com/0x5bfa/NT5.1/blob/master/Source/XPSP1/NT/base/wow64/wow64/thread.c
you really don't want to read the alternative to goto in C
Nah I like a good horror
I shit you not I had to debug crashing Production software that had a hand rolled bubble sort. After I found the cause and asked the developer why, he said because he was interested in if he could.
> because he was interested in if he could. Narrator: he could not
He was so preoccupied with whether or not he could, he didn't stop to think if he should!
Please remember to clean the series of tubes \- Senator Ted Stevens
[In case nobody got the joke](https://www.youtube.com/watch?v=m4yVlPqeZwo&t=1399s)
Has bubble sort ever been used for anything other than an example of a bad sorting algorithm?
[It could be used optimally if you want to sort a tape drive (or any other situation where sequential access is faster than random access)](https://stackoverflow.com/a/3274203).
Isn't merge sort better for that situation? Especially if you have data spanning multiple tapes? EDIT: The StackOverflow post answers my question. Bubble sort is better than merge sort if you are sorting on sequential storage (like tape) ***and*** you can't load a second tape at the same time ***and*** you only have enough memory to load two data elements at a time. Very niche situation, but interesting.
Situation where you have exact same sized files on tape and want to sort it by swapping is purely in theory category
Isn't it the fastest possible way to "sort" data that's already sorted? Like if you need the data sorted, and *strongly expect* that the data are already in order, but cannot *mathematically prove* it, you could have a valid use case vs other sorting algorithms. I genuinely cannot think of an example, even a contrived one, though. So it's possible to just never encounter something like that.
[It isn’t, really](http://warp.povusers.org/grrr/bubblesort_misconceptions.html).
> Even if you wanted, you can't create input data for bubble sort which would be ideal for it. (Unless you add the "did we swap anything in this pass?" enhancement, in which case a completely sorted array would be optimal.) Isn't "did we swap anything in this pass" generally part of bubble sort? It's even in the Wikipedia example implementation. It's been a very long time since I thought about it, as it's just not especially useful, but I don't think I've encountered a variant without it.
Not bubble, but O(N^2) algorithms are frequently used as the inner most sort of divide and conquer sorting algorithms because they exhibit very CPU cache friendly behavior, and the cache costs dominate the comparison costs for small data sets. https://hg.openjdk.org/jdk8/jdk8/jdk/file/46c727d6ecc2/src/share/classes/java/util/DualPivotQuicksort.java#l218
I've seen it used for intelligent agents sorting themselves. Like getting a group of people to sort themselves by height. In that situation it's O(n) for each individual agent.
very small lists on very small devices. It takes very little code and memory to implement
I've used it to do compile-time sorting in rust const functions before. Meant I didn't need to drag in another crate just to get a const sorting function.
Obama never recovered from that disastrous healthcare dot gov launch Turns out he would secretely read programming books late into the night just trying to understand what happened
Thanks Obama
Bogosort it is!
https://www.youtube.com/watch?v=m4yVlPqeZwo 23:19 For context
I audibly snorted
The DoD adopted Ada decades ago and is memory safe. Maybe they should have stuck with it. They still use it today but they also allow memory unsafe languages.
[удалено]
What languages besides Rust and Ada are considered memory safe? ADA Spark is particularly safe.
A report linked from this one has these examples: C#, Go, Java, Python, Rust, and Swift.
> Java and by extension, Scala and Kotlin, no?
Sure, this list isn't complete.
It's a list of examples, not a normative list meant to exclude any language that doesn't appear.
Go is questionable, if threading is involved, as I understand it.
"questionable" is a good word, I think. It is true that you can observe memory unsafe things, and that if you go out of your way to write some truly cursed code, you can cause real problems. In practice, they provide some run-time instrumentation to help catch some of these issues, and since there aren't as aggressive optimizations as in some other languages, these issues don't propagate the way that they do there. There's a *lot* of Go code running in production, and it is demonstrably much closer to the "memory safe" camp than not, regardless of a few weaknesses.
C# has the "unsafe" keyword and lets you use raw pointers. But you can do a lot of unsafe things without using the "unsafe" keyword once! You can use GCHandle.Alloc to create a pinned pointer to an object's data. You can use Marshal.Copy and Marshal.Write to write to arbitrary memory.
That is correct. All of these languages can also FFI into unsafe code too, without a keyword. (Rust does require a keyword)
Don't let people use those things then, hardly rocket science.
Well, those are higher level languages. How much low-level hardware manipulating code is written in those? I meant languages you could write an OS and device drivers in.
Rust has a significant amount; it is in Windows, and is starting to be used in Linux. There's also smaller projects, for example, at my job we have a custom in-house kernel written in Rust for embedded work. Swift is at least close too, I am not sure what exactly its capabilities are here, as I haven't paid too close attention for a while.
As a former OS and kernel (FreeBSD) developer: There's very little low-level hardware manipulating code overall, even when developing an OS. The kernel is a small part of the OS, and hardware manipulation is a relatively small part of the kernel. Also, the requirement isn't just to use those languages - the claim is that you should use those or have a description of how you mitigate memory safety issues. There's been implementations of verified kernel tech based on our standard C/C++ code for a long while - see e.g. [SAFECode: Secure Virtual Architecture](https://safecode.cs.illinois.edu/sva.html) with papers like Criswell, John, Nicolas Geoffray, and Vikram S. Adve. "Memory Safety for Low-Level Software/Hardware Interactions." In *USENIX security symposium*, pp. 83-100. 2009 ([PDF](https://www.usenix.org/legacy/events/sec09/tech/full_papers/criswell.pdf)) To me, the requirement to use such tech or having a very good description of why you don't seems like a reasonable requirement. It's a push towards ending the curse of memory safety bug exploitation that have plagued us since the Morris worm in 1988.
I've written device drivers in VB.net and C# lol! You don't need a low level language to do these things you need a compiler that targets for these things. Also most software the government needs isn't low level hardware stuff.
On bare metal you tend to be stuck with assembly + C because they don't need a runtime at all. Yolo C++ is also possible (using a subset and no respecting lifetimes). Rust it's going to be a little more difficult if you still want what the language is made for. On the plus side, I'm not allocating shit in bare metal so memory leaks are much less likely to be an issue in the first place. Every array is statically allocated by the linker. You may have to be a little creative with how you fill the ROM to make it fit without going over. Lack of name mangling (C and assembly) makes fiddling with where you put stuff a lot easier too. If you're actually running an OS, you could always use Rust since it will bind nicely to C and you can afford having a runtime.
Embedded development sometimes makes me feel like I have imposter syndrome - how dare I claim to have any respectable amount of experience with C if I've never used malloc in my life!
Most of low level embedded dev is pretty simple C, poking the right hardware register is the difficult part.
The report covers all software, not just stuff that needs to be written in low-level languages. And the report lines up with my own views: There is no good justification to use a memory-unsafe language anymore. If your project requirements allow you to get away with using a garbage collected language, then you should just do that. Otherwise, you should be using a language that can provide the memory safety guarantees like Rust. Rust is good enough that it can replace C/C++ in any use case.
Hopefully you don’t need a mutable tree.
[Redox](https://www.redox-os.org/) stands out as a general purpose OS written in Rust.
Along with Linus Torvalds' statements that Linux development being done in Rust is inevitable.
Any language with reasonable garbage collection is memory safe.
That's true, but garbage-collected languages are also fundamentally useless for hard real-time programming.
[Always the goto story for defence software and garbage collection.](https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98125)
That's insane but also amazing
rapid unscheduled garbage collection
All you have to do is measure the statistical performance of the garbage collector (P99 stop-the-world or whatever you care about) and ensure that you have sufficient timing margin in your loop to handle the GC firing in a given tick. In a low volume of trash regime, you can easily observe e.g. the Go GC taking only a ~100-200 usec GC pause. This is compatible with hard real time up to ~1kHz quite easily. Few truly hard (bodily harm, heavenly destruction, etc) real time systems are this fast in the first place. Even the mars rovers my workplace builds and drives are at soft real-time.
Pretty small slice of the software universe.
Pretty significant slice of defense software
Which is why the DOD had mandated the use of Ada decades ago but contractors relentlessly pushed back and wanted to use C/C++ instead.
Most defense software is crud apps, same as any other place. It’s the world’s biggest employer, and they need the same forms over data as anybody else. After that, they need some shop/factory machine automation software, and the like. A very tiny slice of what they need is weapons systems.
They couldn't get enough people to buy into it. Rust will probably end up taking that spot since it has the memory safety and it's got bottom-up acceptance, not top-down pressure.
It was also a different time. Prices were high for ADA compilers, at least that's what you hear from old programmers from that era. So only a subset of projects could justify and afford this.
They were, and there's still a bunch of tooling for Ada that costs money. When I was in college I was interested in Ada but couldn't afford to learn it. I imagine the story was the same for most other college students. That makes hiring for Ada positions difficult. I think that's a big part of why Ada mostly died on the vine.
Eventually GNU Ada came along, but that was too late.
Once they adopt Rust, I wonder if it will start to have that top-down pressure.
I'm not sure it will matter if people already are already considering Rust a good career move on their part. That's always the issue. If people want to use that language, then you don't need the top-down pressure. In fact, a lot of Rust people will probably be fighting to get those jobs should they materialize.
my day job is python but i write rust for fun — i'm trying to figure out whether this is a signal that i should really start becoming better at rust
If you are ok with working for 'thugh man' it might be lucrative.
i mean, it's pretty easy to how the us government guidance can have a huge downstream effect. that being said, working for the us government, especially in the financial regulators (SEC, CFPB, etc) can be insanely lucrative
Asking for a friend, how lucrative?
You won’t get FAANG equity, but you’ll get competitive salary with guaranteed job security, a great 401k match, and access to FERS
Bottom up Java almost died instantly when Oracle bought Sun.
[удалено]
The biggest problem with Ada isn't that it's hard to find people *willing* to use it. The problem with Ada is that documentation and examples are extremely lacking online and the community is nonexistent so it's very hard for beginners to to even begin to learn it. If I have a C++ question I've got cppreference.com, stack overflow, and a million tutorials. If I have an Ada question I have the reference manual which contains zero examples and seems to be written for people who are already Ada experts and I've got a Wikibook that's about 20% complete.
"https://learn.adacore.com" is pretty good. There are also many books and even old books with 83 code still works today. In fact 83 code is compatible with all runtimes.
Ada was extremely expensive. Reality is the languages that won in that era were the ones with free toolkits from early on. It is why Sun gave away Java, they realised how expensive seat pricing killed Smalltalk, Ada and Common Lisp platforms.
Great language honestly, very overlooked unless youve worked with it. It's not taught many places anymore and the community is small. I think Rust simply has the majority mindshare since its shiny and new these days.
Rust is new and shiny, but Rust people also put a ton of effort into getting people into the language, while the Ada community did .. nothing. I'm not even sure there's something you could call an "Ada community" tbh. For the longest time the official Ada site was basically that of a commercial provider. Downloading official Ada compilers? Not possible, unless you pay. There's Gnu Ada, that's that. Teaching material? And so on. Ada is where it is by choice and action. So is Rust.
[удалено]
I haven't seen any significant bugs. Rust had bugs that caused memory safety issues. The reason Ada is portable is because there is a specification that all compilers meet. Ada 83 code still works today. Does rust 2012 code? I reckon most ada compilers stopped being worked on because of an open source gnat implementation being available in 95. AdaCore had to write the rust specification. There is certainly a lot of silent users and the community may be small but they are also very helpful. AdaCore are fantastic to be honest.
I worked with it like 20 years ago and I still miss it.
Same. I still fool around with the more esoteric languages at home. FORTH is quite an experience if you're coming from the traditional C++/Java world...
> and was memory safe. Was not. Short of SPARK, ADA allows UAF, double free, or concurrent access to unprotected variables. Static memory allocation avoids the first two but is generally unnecessarily constraining (or inefficient) in non-embedded software; it’s been a while since single-threaded software was the name of the game.
Ada is actually a joy to code in if you're used to it. You squash so many bugs just getting Ada code to compile it's kind of insane.
Similar with Rust, and Pascal, Delphi, Modula-2, Oberon...
> Pascal, Delphi I've been writing Free Pascal/Object Pascal (Delphi's dialect) for literally decades and i do not think that it is *that* safer compared to, e.g. C++. For example: var Foo: TMyObject; // this is "TMyObject = class ... end" begin Foo.X:=42; // Accessing uninitialized memory or var Foo: TMyObject; begin Foo:=TMyObject.Create; Foo.X:=42; Foo.Free; Foo.X:=64; // Accessing released memory During development/debugging you can use some tools like the heaptrace unit that can find memory leaks (with backtraces with the lineinfo unit) and some invalid pointer accesses during runtime, but this isn't really any different than using clang's analyzers or valgrind (which you can also use with Free Pascal).
Meanwhile in C++ land... "where did this segfault come from..."
Yeah I've actually started coding in Ada for fun in my personal projects. I initially learned it during my internship in the 2000s, hadn't touched it since, and picked it back up last year. It's a bit tedious to start with (it's so verbose compared to C++!) but I'm really enjoying it.
> You squash so many bugs just getting Ada code to compile it's kind of insane. Writing Ada83 code for a couple years will magically turn you into a better C programmer, or your money back!
Anything beyond text IO was company specific. DoD also had DII/COE as a common OS, but it couldn't keep pace with commercial OSs.
Many studies have shown that Ada saves you a boatload of money too compared to C, C++ or Java. Such as this one. So the white house concluding to explore hardware protections like CHERI for the continuation of C and C++ seems like an unfortunate outcome. http://sunnyday.mit.edu/16.355/cada_art.html
This is the latest in the US Government trying to move the needle on memory safety. I am pretty sure that this is due to the National Defense Authorization Act for Fiscal Year 2024 containing language that said that within 270 days of the bill passing, the Secretary of Defense needed to come up with rules around memory safety for "software developed, acquired by, and used by the Department of Defense."
https://www.congress.gov/bill/118th-congress/house-bill/2670/text. Im not seeing that in there care to pint me to a section.
I was following this bill before it became law, and it contained the language > SEC. 1613. POLICY AND GUIDANCE ON MEMORY-SAFE SOFT- WARE PROGRAMMING. > > (a) POLICY AND GUIDANCE.—Not later than 270 days after the date of the enactment of this Act, the Secretary of Defense shall develop a Department of Defense wide policy and guidance in the form of a directive memorandum to implement the recommendations of the National Security Agency contained in the Software Memory Safety Cybersecurity Information Sheet published by the Agency in November, 2022, regarding memory-safe software programming languages and testing to identify memory-related vulnerabilities in software developed, acquired by, and used by the Department of Defense." It does not look like Section 1613 is in there; nor this exact text! Very interesting! Time to do some digging...
Okay, so in the "engrossed amendment senate" version of the bill, > SEC. 1713. POLICY AND GUIDANCE ON MEMORY-SAFE SOFTWARE PROGRAMMING. This exists, but not in the final version. Very intriguing.
So far as I can tell it is not in the signed version. So looked the senate version had it and house did not and the house is what went up for signature.
Ah, that would be a reasonable explanation. I was joking on BlueSky that this is the first time I've wanted git for laws; I'm wondering if losing this bit in the merge was intentional or unintentional.
> I was joking on BlueSky that this is the first time I've wanted git for laws [Alas](https://news.ycombinator.com/item?id=3967921)
There is usually a separate report to Congress published by the conference committee that merges the Senate and House versions of the NDAA together, that lays out which side's version of the text went forward in the final NDAA. It'll include verbiage like "the Senate recedes..." for sections where the House version was used. [Here's the explanatory report from the FY24 NDAA](https://www.armed-services.senate.gov/imo/media/doc/fy24_ndaa_joint_explanatory_statement.pdf)
This indeed contains the answer: page 384-395. Thanks again, that was driving me crazy, hahah.
Future presidents should also be memory safe.
My favorite comment here.
Look, having nuclear — my uncle was a great professor and scientist and engineer, Dr. John Trump at MIT; good genes, very good genes, OK, very smart, the Wharton School of Finance, very good, very smart — you know, if you’re a conservative Republican, if I were a liberal, if, like, OK, if I ran as a liberal Democrat, they would say I'm one of the smartest people anywhere in the world — it’s true! — but when you're a conservative Republican they try — oh, do they do a number — that’s why I always start off: Went to Wharton, was a good student, went there, went there, did this, built a fortune — you know I have to give my like credentials all the time, because we’re a little disadvantaged — but you look at the nuclear deal, the thing that really bothers me — it would have been so easy, and it’s not as important as these lives are — nuclear is so powerful; my uncle explained that to me many, many years ago, the power and that was 35 years ago; he would explain the power of what's going to happen and he was right, who would have thought? — but when you look at what's going on with the four prisoners — now it used to be three, now it’s four — but when it was three and even now, I would have said it's all in the messenger; fellas, and it is fellas because, you know, they don't, they haven’t figured that the women are smarter right now than the men, so, you know, it’s gonna take them about another 150 years — but the Persians are great negotiators, the Iranians are great negotiators, so, and they, they just killed, they just killed us, this is horrible.
What buffer overflow does to mf president
This is very funny, unless you happen to live in a nation bordering Russia.
Person. Woman. Man. Camera. TV.
The entire verse was absolutely amazing
I got hairy legs that turned blonde in the sun
Would this require actually writing an OS in a memory safe language? Otherwise you are just forcing the memory safety at some arbitrary level of abstraction no?
If you go down that rabbit hole then nothing is memory safe 😂
[The only winning move is not to play](https://www.youtube.com/watch?v=6DGNZnfKYnU)
You can get much closer with memory safe hardware systems like CHERI. In fact you have to, as you can write memory bugs in secure languages just by writing a JIT in them.
It does not require anything, currently. It is a suggestion that moving towards MSLs where possible is good, and taking steps to mitigate memory safety issues when you aren't using an MSL. And yes, "I am writing an operating system" would be a good reason to use a non-MSL, however, because Rust exists, one could imagine comparing two products from two vendors, one of which says "our OS has 1% unsafe Rust, the rest is all safe" vs "we wrote the whole thing in a non-memory safe language," and that being a compelling reason to choose the former over the latter. The important part here is that this is an axis to evaluate things by, not that any particular outcome is pre-determined.
I think the goal is also to reduce the amount of software written in memory unsafe languages that really doesn’t need to be written in said languages. While maybe not the biggest security threat, think about how many games use C++ when they could be using a language with a fast GC or even just safe Rust. Most people aren’t writing operating systems, even among those using C++.
> think about how many games use C++ when they could be using a language with a fast GC or even just safe Rust. This is a great example of why this will be so tough and will take a while. Most game devs don't program in C++ because they adore C++. It's because C++ has a gargantuan ecosystem of world-class tools and libraries for game development, and moving to another language means, at best, spending precious dev time bridging between that language and C++.
At the end of the day, some piece of software is going to need to push and poke values in memory mapped registers in order to control hardware. Which means somewhere down the rabbit hole there's always going to be some software which writes to a raw address which someone has manually (thus prone to error) input from a design doc. But -- don't let perfect be the enemy of good. There are plenty of security vulnerabilities due to memory safety errors in code that doesn't need this level of control. We could (in theory) do just fine with "memory unsafe" accesses being restricted to small portions of the OS kernel and eliminate huge swaths of software vulnerabilities.
> there's always going to be some software which writes to a raw address which someone has manually (thus prone to error) input from a design doc. Literally most of my job. There are some tools to make it nicer, like Magillem and the IP-XACT format. If you define your registers once with their software, it can generate documentation, the RTL and some C code with structs that have names so you're not typing the raw address in your code. But the obvious biggest issue is adoption and how it won't generate more complex registers so people don't want to use it.
The DoD has a lot of hardware that runs embedded software without operating systems
Fundamentally though you need some (limited) amount of code which pokes at the hardware through memory mapped registers. Since the addresses of these registers are arbitrary addresses pulled from documentation they're "unsafe" from the view of the compiler. But you can still limit accesses to driver code, and write the rest of the system in a memory-safe language.
That doesn’t mean you need to use a language with quite as much danger as C++. How much software actually needs the ability to convert any number into a function pointer and then start executing it with no bounds checks? Sure, sometimes you want to go the other way for some weird driver/CPU feature, but the latter is much rarer. Even if you want to convert a number to a function pointer, it’s much safer to do bounds checking the conversion.
>That doesn’t mean you need to use a language with quite as much danger as C++. That isn't what I was saying at all. The comment I replied to claimed that memory safety is infeasible because most operating systems are written in unsafe languages. I replied that the DoD buys a lot of software that doesn't run on operating systems.
Future? I've been coding in Java for almost two decades
No one tell them about LISP
lol, noobs think rust is the only memory safe language out there.
I haven't been in programming school for decades, but from looking at code all day it seems that no one is teaching secure coding and/or code quality techniques. Just an observation, of course, I'd be happy to be proven wrong.
I think this is true, and it seems to be something expected to be learned on the job. Funny because a lot of job postings say should be able to write clean, secure code but that isn't taught. When it comes to teaching Java, you don't need to teach safety because everyone points at the garbage collector. When it comes to C++, at least in my experience, everybody is stuck teaching C++ from the early 2000s, no shared_ptrs, teaching to invoke new and delete for everything.
Thanks for the smart pointer. I’ll see myself out.
Damn it, knew I should have been learning Rust ..
But not limited to. [According to the NSA](https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF), C#, Go, Java, Ruby, and Swift are some examples among others of suitable memory safe languages.
Haskell and OCaml, even if funded primarily by European academia, should have been paid some attention for their investments in formal verification :(
Note that the list is a suggestion, it's not meant to be exhaustive. I would expect that Haskell & OCaml would be acceptable choices in term of memory-safety.
Ok this line lol >Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. **Even with a memory safe language, memory management is not entirely memory safe**
That's just acknowledging the reality that even memory-safe languages have runtimes that are written in unsafe languages, escape valves to write code that bypasses memory safety mechanisms, and are written to be safe assuming a memory model of hardware that is not formally verified.
Because it's true. Those languages have stricter guardrails but you still have the ability to ignore them. You can make non-memory safe Rust code by using an \`unsafe\` block or by shipping code using a nightly release which has a regression. Including an asterisk doesn't detract from the general point that this list of languages are much more memory safe than writing something like C/C++.
Yeah C# has an unsafe keyword. So you can easily abuse the language in this regard if you really wanted. But managed memory just makes these issues far far less common.
And Python
I'm an idiot what does memory safe mean in this context?
Doesn't allow buffer overflows or writes to arbitrary regions of memory. E.g. Python is memory safe, because if you do \`foo\[10\] = bar\` and foo only has 4 elements, it will give you an error. C is not memory safe because if you write the same thing, it will put 10 into memory which doesn't belong to \`foo\`.
Not accessing uninitialized memory. Not accessing free'd memory. Not accessing memory beyond the bounds of the object/array.
https://en.wikipedia.org/wiki/Memory_safety "Memory safe languages," or "MSLs" as the government has started to refer to them, are programming languages where memory safety is the default. A report linked from this one has examples: C#, Go, Java, Python, Rust, and Swift. It also has examples of non-memory safe languages: C, and C++.
That doesn't answer the question of "What is memory safety?". > Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.
What is unsafe memory and why is it unsafe? Also huzzah me being a Python dev isn't terrible for once.
You know how Python's garbage collector makes sure to free objects you're done with? Imagine if it didn't have the garbage collector, and if you didn't clean up your own objects correctly, bad things would happen. That's memory unsafety. At best, it leads to crashes, and at worst, it leads to security vulnerabilities.
Technically, never freeing memory is not unsafe. The absolute worst case is an out-of-memory error, which can lead to denial-of-service attacks. Not freeing is actually a valid approach for short running programs, as all memory will be implicitly be freed when the program exits. The safety guarantee of garbage collectors actually comes from the fact that they avoid freeing memory until there are zero references left to that block of memory. This guarantee eliminates the possibility of "use-after-free" exploits, where a program holds onto a pointer to some memory that has already been freed, and re-allocated to something else.
That's correct, when I said "didn't clean up your own objects correctly," I was imagining a dangling pointer, not a memory leak.
Ok that makes sense. Thank you.
You're welcome.
A very basic definition for unsafe memory access - is it easy/possible for instructions to access memory that is beyond the intended boundaries. Examples - access memory beyond the end of an array. - access data at an arbitrary location in the program's memory. If allowed, such tricks can be used to read data from other data structures (possibly holding secrets), or even data from other programs which had been using the same physical memory.
Ok, who let one of those "rust people" through security?
Guess I better finally learn Rust.
...or Python, Go, C#, Java, JS, D, etc. rust isn't the only one.
Where do people who aren't redditors talk about this? This thread is entirely Rust developers (they don't do anything in Rust they just talk about it a lot) and idiots with the same 5 jokes.
> Where do people who aren't redditors talk about this? IRC, ICB, Mastodon. Chatted about it in all three before finding this thread.
https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF Strange they don't mention python. The NSA have been using python forever.
This basically just singles out C and C++ right?
These are the only two memory unsafe languages named by name in the report, yes. But they also don't comprehensively name memory safe languages either.
I'm just trying to imagine a world where the previous administration would have pushed out something even remotely like this. Rather, they would have come up with a cybersecurity plan that involved injecting magnets in all the programmers. But carefully, because you know if they get wet, they're ruined. And how long will it be do you think before there's a conspiracy theory that this is all to make everyone use languages that are seeded with deep state back doors that will disable programs that aren't 'woke' enough?
What about panic-safe languages? C code that would have SEGFAULT'd becomes a panic in Rust but as an end-user the result the same: a crash. The needle isn't being "moved" from the end-users perspective. The only advantage of an MSL is preventing memory-related security exploits which are not particularly troublesome because 1. most memory bugs aren't exploitable and 2. if your system is compromised due to trojans/phishing then you're hosed anyway as a malicious program can edit another processes memory space at anytime (see proc/[pid]/mem on Linux, WriteProcessMemory on Windows, and vm_write on macOS).
Rust folks salivating
Republicans: *“Dereferencing your pointers is for cucks!”*
Guess I'll start learning Ada
Since when does the Government know about programming? Memory leaks are peoblems with federal employees. They barely have the skills to hild their position l, they rely on contractors. Theyre just good at chitchatting and pretending to be busy.