White House Urges Devs To Switch To Memory-Safe Programming Languages (infoworld.com) 228
Tontoman shares a report: The White House Office of the National Cyber Director (ONCD) urged tech companies to switch to memory-safe programming languages, such as Rust, to improve software security by reducing the number of memory safety vulnerabilities. Such vulnerabilities are coding errors or weaknesses within software that can lead to memory management issues when memory can be accessed, written, allocated, or deallocated. They occur when software accesses memory in unintended or unsafe ways, resulting in various security risks and issues like buffer overflow, use after free, use of uninitialized memory, and double free that attackers can exploit.
Successful exploitation carries severe risks, potentially enabling threat actors to gain unauthorized access to data or execute malicious code with the privileges of the system owner. "For over 35 years, this same class of vulnerability has vexed the digital ecosystem. The challenge of eliminating entire classes of software vulnerabilities is an urgent and complex problem. Looking forward, new approaches must be taken to mitigate this risk," ONCD's report says. "The highest leverage method to reduce memory safety vulnerabilities is to secure one of the building blocks of cyberspace: the programming language. Using memory safe programming languages can eliminate most memory safety errors."
Successful exploitation carries severe risks, potentially enabling threat actors to gain unauthorized access to data or execute malicious code with the privileges of the system owner. "For over 35 years, this same class of vulnerability has vexed the digital ecosystem. The challenge of eliminating entire classes of software vulnerabilities is an urgent and complex problem. Looking forward, new approaches must be taken to mitigate this risk," ONCD's report says. "The highest leverage method to reduce memory safety vulnerabilities is to secure one of the building blocks of cyberspace: the programming language. Using memory safe programming languages can eliminate most memory safety errors."
Nooooo (Score:5, Funny)
Liberals coming for my compiler! Guns are next!
Re: (Score:2)
Re: (Score:2)
I'd have to transit to Fortran then because I don't have a gun, and the only gun I'd like to have is the Swedish K.
Re: (Score:2)
irony.
fortran is the favored language used by nasa
Re:Nooooo (Score:5, Funny)
Be sure to understand opening clause (Score:5, Insightful)
A well mallocated pointer being necessary to the security of a free() call, the right of the programmer to write C, shall not be infringed.
Note that the introductory clause is just an example usage of C, it does not restrict C to only those implementations that directly use stdlib malloc/free.
Re: (Score:3)
dude, chill, this is just some overpaid white house employees having fun with chatgpt.
Re:Nooooo (Score:5, Funny)
Don't worry: The 1st ammendment gives you the right to peacably assemble.
Re: Nooooo (Score:3)
My kingdom for a mod point!
Re: Careful with that patriotically assembling (Score:3)
The Patriot Act killed my enthusiasm for the word.
Re: (Score:2)
Re: (Score:3, Insightful)
And your boobies.
Re: (Score:2)
My computer had better not seize up while searching.
Re: (Score:3)
What's the matter with the Ada language? (Score:2)
The US Government already promoted use of a "safe" programming language (OK, OK,. it's French in origin, but still).
Why are they reinventing the wheel and nagging the adoption of Rust?
Re: (Score:2)
Re: (Score:2)
wrong.
keyboards are next.
a report will be made public that demonstrates all evil hackers use them
Re: (Score:2)
The '90s called. (Score:5, Interesting)
They'd like to have their buffer overflow angst back.
I mean, they're not wrong but surely this is common knowledge by now. No one codes in C without realizing memory management and buffer overruns is a problem.
Seriously. Go fix some real problems like standardizing password complexity rules or encouraging developers to use alternatives to passwords.
Re:The '90s called. (Score:5, Interesting)
No one codes in C without realizing memory management and buffer overruns is a problem.
Plenty of people do, especially the JuSt DoNt WrItE bUgS crowd.
Back in the real world something like 70% of CVEs are memory related fuckups. Clearly, lots of people are writing in C who don't get this stuff correct. Any claim to the contrary flies in the face of evidence.
Writing safe C code is very expensive and people are less productive doing so. Compare SEL4 (safe C) to OpenBSD (merely very good C) to Linux (C). Which one are you actually going to use?
Re: (Score:2, Interesting)
>Plenty of people do, especially the JuSt DoNt WrItE bUgS crowd.
Regrettably so. I still occasionally encounter people who look at C as a "real programmer's" language and who have disdain for memory safety constructs, which are seen as nerfing a language.
IMO this kind of overconfidence is both juvenile and counter to the engineering ethos of having public safety in mind.
Re: (Score:2)
Why don't we Amend the C language to make the fuckups harder?
Add these features
1. Automatic initialization of newly-defined variables to 0. For example char buffer[256] creates a character variable, And automatically initializes it to all zeros.
2. Automatic tracking of pointers. When an object is free()'d with free(pointer), then the runtime should Automatically zero all variables that pointed to that object.
3. Automatic tracking of the Boundary address of the object pointed to by a pointer.
char
Re:The '90s called. (Score:5, Insightful)
Re: (Score:3)
Mostly performance.
Just to pick the low-hanging fruit here, your automatic initialization of a 256 char buf takes a lot of cycles. Later on, the function may not even need to access the buffer, or it might only need to write part of it.
This is the kind of thing the Rust guys gave a lot of thought.
So let's say instead that at compile-time, char buf[256] generates a compiler warning: WARNING. DECLARED array of raw char. It still compiles, but it warns.
Instead, let's add zchar to the language. This does
Re: The '90s called. (Score:2)
Program in MISRA C. select abd use a functional safety development process that ensures bidirectional traceability. And leave the people who want to use vanilla ISO C alone.
Re: (Score:3)
1. Automatic initialization of newly-defined variables to 0. For example char buffer[256] creates a character variable, And automatically initializes it to all zeros.
Because not all memory accesses are accesses to memory.
2. Automatic tracking of pointers. When an object is free()'d with free(pointer), then the runtime should Automatically zero all variables that pointed to that object.
That should do some fun shit with DMA controllers.
Has it occurred to you that maybe you don't really understand all the use cases for the language?
Re: (Score:3)
>2. Automatic tracking of pointers. When an object is free()'d with free(pointer), then the runtime should Automatically zero all variables that pointed to that object.
Thats expensive at run-time, both in time and the amount of runtime code needed to manage it. It's impractical in C as a language to track all holders of a pointer. If it was easy then garbage collectors would be easy.
3. Automatic tracking of the Boundary address of the object pointed to by a pointer.
Also expensive. Each operation spends extra code validating the access.
These are things that Rust already does - but when used in embedded or real time system, programmers usually turn off these checkers. These are things C++ also does, if you use the new types. The "new" C language would a
Give them to anyone, which the predictable results (Score:2)
No one codes in C without realizing memory management and buffer overruns is a problem
I heard the same in the 80s. I expect it was also claimed in the 70s. :-)
There is no licensing or proficiency testing for obtaining a compiler. They will literally give them to anyone, which the predictable results.
Re: The '90s called. (Score:5, Insightful)
Writing safe C code is very expensive and people are less productive doing so.
Not always. For some people, it just becomes a habit.
And those people tend to be very expensive.
Re: (Score:2)
https://www.snopes.com/fact-ch... [snopes.com]
Re: The '90s called. (Score:2)
But it will still be cheaper than hiring bad programmers coding in a memory safe language.
Everyone should be forced to learn coding C under MS-DOS. It's unforgiving and you'll learn quickly the effects of dirty programming and out of order malloc/free causing memory fragmentation.
Re: (Score:3)
Good code is expensive. Also Rust is new and very few people know it, and those who do know it have only a few short years of experience in it. Thus "Good Rust Programmers" are damned expensive.
Re: The '90s called. (Score:5, Interesting)
Not always. For some people, it just becomes a habit.
Not enough. SEL4 didn't achieve safety by people writing C really really well and being super awesome. They achieved it by doing a ton of research in formal methods to prove the design correct and fail it when it was not mechanically provably correct.
OpenBSD has repeated audits and they have a history of developing new tech to work around C's shortcomings because even they know they won't always get it right.
Because there's no telling how many other types of errors they will make that Rust cannot catch.
They're already making those errors plus memory errors in C. With not C, the memory errors go away. Plus you know Rust isn't the only choice. If they want to have even fewer errors, there's always SPARK.
Bad Car Analogy: Traffic would be a lot less gridlocked if the only people granted licenses had to show proficiency in driving a stickshift.
I don't get the analogy (I'm from the UK where everyone drives a manual, so I expect I'm missing some cultural context).
Re: (Score:2)
I don't get the analogy (I'm from the UK where everyone drives a manual, so I expect I'm missing some cultural context).
I can only guess it is a True Scotsman logical fallacy. Only "real" drivers know how to drive a manual thus they are superior.
Re: (Score:3)
Ada is still 100 times simpler than the current C++ standard :-)
Re: (Score:2, Redundant)
I mean, they're not wrong but surely this is common knowledge by now. No one codes in C without realizing memory management and buffer overruns is a problem.
So you are confirming that C is not memory safe as the White House alleges then? And your solution to the problem is what? Do nothing?
Seriously. Go fix some real problems like standardizing password complexity rules or encouraging developers to use alternatives to passwords.
Well that's a red herring and false dichotomy in one. They are suggesting possible ways to mitigate Problem A. You've dismissed it by complaining about Problem B.
Re: (Score:2)
So you are confirming that C is not memory safe as the White House alleges then?
Ultimately everything backs up to a CPU that is not memory safe.
High level languages can Add a lot of safety features, But high-level languages are also slow,
All the extra features of high-level languages add cost which can be so high that many things can't be written in a high-level language.
Because HLLs add ineffiencies; which lose you Time, performance, and of course energy efficiency.
For example, the last thing you want i
Re: (Score:3)
Ultimately everything backs up to a CPU that is not memory safe.
And whoever said that the recommendation was everything must be 100% memory safe? No one. Some languages like Rust offer better memory protection than others like C. That is the recommendation: use languages that offer better memory protection.
High level languages can Add a lot of safety features, But high-level languages are also slow, All the extra features of high-level languages add cost which can be so high that many things can't be written in a high-level language. Because HLLs add ineffiencies; which lose you Time, performance, and of course energy efficiency.
The recommendation is to use more memory safe languages. The recommendation is not to switch everything to high level. For example, Rust can be used for low level programming.
Re: (Score:2)
Seriously. Go fix some real problems like standardizing password complexity rules or encouraging developers to use alternatives to passwords.
NIST already did that about 7 years ago. [nist.gov]
Re: (Score:3)
"Seriously. Go fix some real problems like standardizing password complexity rules or encouraging developers to use alternatives to passwords."
Spoken like someone far outside of the infosec space.
There is literally an organization inside of the United States Federal Government that does just this:
https://pages.nist.gov/800-63-... [nist.gov]
Re: (Score:3)
The standard is woefully out-of-date and needs to be rewritten.
Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters
The entire 8-character namespace can be brute forced with many of the password hashing schemes in use for verifiers; an attacker with a GPU farm can exhaust the whole of 8 character MD5 hashes within about 10 minutes.
They should have recommend that memorized secrets Not b
Re: (Score:3)
an attacker with a GPU farm can exhaust the whole of 8 character MD5 hashes within about 10 minutes.
So use a different hash algorithm. If you're using MD5 for anything, you're asking for a beating.
They should have recommend that memorized secrets Not be used as a primary authentication factor.
That's the only authentication mechanism that is easily changed when compromised. It has it's role in modern authentication precisely because of that quality. Demanding it be removed only shows that you value convenience more than actual security.
SSH's Public key challenges; Push-based authenticator apps
Both of these requires the authentication keys to be on an internet connected device. Insecure.
Smart Cards with a PIN+Challenge, FIDO2 security keys
These require the device holding the authentication keys to be direct
Re:The '90s called. (Score:5, Insightful)
The snag is that the Rust missionaries are persistent in their proselytizing. Get just one advocate on your team and suddenly the VP is holding meetings to investigate the Rust idea...
This is not a new idea to throw out decades of code and start from scratch (the minor increase in quality will more than pay for the multi-year total conversion project). Way back when on an embedded project one new employee who was currently learning Java was adamant that we convert a working project on a 50 person team to be Java. On an 8086, for a real time system, when there were not native code compilers for Java. We disagreed because it was utterly impractical; could not be done, would be too expensive, etc. He refused to listen to any of the reasons and went and quit, started his own company doing Java, and at a Java One conference he gave a key note address where he badmouthed the previous company. In some people the zealotry takes a firm hold and won't let go. And I see that attitude in many Rust advocates.
The snag for me is that anything with a long list of "pros" but no "cons" is indistinguishable from a scam. I'd trust a Rust a lot more of its missionaries would just admit that it's not perfect.
Think twice? (Score:5, Funny)
Re:Think twice? (Score:5, Insightful)
How is the NSA going to do its job when all programs are memory safe?
Backdoors.
Re: (Score:2)
Also, hammer attacks to use normal if malificent code to flip bits in nearby wires, that's some Doctor Doom level stuff.
And, of course, good old social engineering.
Re: (Score:2)
How is the NSA going to do its job when all programs are memory safe?
Backdoors.
Backdoors inserted by the compiler.
Re: (Score:2)
Every memory safe language has a Memory Unsafe language under the hood.
This is a good idea (Score:5, Insightful)
There will be slashdotters who argue that unsafe languages are perfectly fine, you just need to hire competent programmers. They're idiots. Well, that's not really fair; they're not so much idiots as people who don't want to learn something else trying to defend their skillset. But if there's one thing we've thoroughly proven in software development over the last few decades it's that even the most competent programmers make mistakes. This shouldn't surprise anyone -- we're human! But this is why we build tools to help us.
Most software development has already switched to managed languages that use run-time bounds checking and garbage collection to avoid huge numbers of pitfalls. These languages are more efficient with developer time, which is far more valuable in most cases than machine time, so nearly all application development has moved to them. Javascript, Java, C#, Python, Go, etc.
But some software, especially system software, really does need higher performance and more predictable execution times than you can get with managed languages with GC. Until recently, Modern C++ (C++ that relies heavily on RAII, eschews naked pointers almost entirely, etc.) has been our best option for writing high-performance, tight code with minimal risk of serious memory management mistakes or bounds errors. It still requires discipline, because you have to follow the Modern C++ guidelines. Tooling can help to detect when you stray from them.
Rust is, I think, a better solution for this context.
I write security-critical code, code that uses cryptography to bootstrap core security features for the world's most popular consumer operating system (Android). We've been experimenting with and using Rust for the last 3-4 years, and it's just plain better. Once engineers learn the language well, they get stuff done as fast or faster than with C++ (which is in turn much more efficient in terms of developer time than C), and there are far fewer bugs. Obviously there are basically no memory bugs or integer overflow bugs, and Rust also helps to avoid some concurrency bugs. We're using it both in "big system" configurations (Linux, i.e. normal Android) and in tiny embedded environments, such as in the Titan M secure element. The latter is more difficult, because many of the libraries aren't available in "noalloc" configurations ("noalloc" means no heap, basically; all memory allocation is static), but it's getting better and is actually somewhat easier to work with than C++ in very constrained environments.
If you do low-level microcontroller development, OS development, game engine development, etc., you should give Rust a serious look. If you do application development you should use a managed language.
Re:This is a good idea (Score:5, Interesting)
As you say, Modern C++ allows for one to adopt the primary selling point of Rust: memory safety. Furthermore, because C++ has been around for ages, developers have access to a much higher breadth and depth of libraries and frameworks (e.g., Eigen for linear algebra). So, there does not really seem to be any particular advantage to using Rust.
Re: (Score:2)
Re: (Score:2)
The language could be safe, but all those block pointers to pass non-trivial amounts of data to OS still exist. So the OS must be that way, too, and still couldn't trust the block was free and clear.
Re: (Score:3)
Re: (Score:2)
Windows uses a lot of C++. Also; there was recently some Patch request about changing the Linux kernel to C+;
that could possibly happen soon
Re: (Score:2)
Re: (Score:2)
Also; there was recently some Patch request about changing the Linux kernel to C+;
that could possibly happen soon
I take it that was a language compromise between the C programmers and the C++ programmers?
Re: (Score:3)
Re: (Score:3)
You seem pretty confident. Are you a kernel developer who regularly talks with Linus to know what's on his mind?
Linus has publicly stated his thoughts on C++ especially for the Linux kernel: "C++ is such a bad language!" [medium.com] as of 2021. Going back to 2007 when a developer criticized using Linux kernel development using only C as "BS" and advocated using C++, Linus responded, “I will not use C++ and programmers who develop projects instead of C are kicked out, lest they mess up the projects I’m involved in”. I do not need to read his mind on this topic.
C++ is already widely used in embedded programming, and performance and efficiency really matter there. So there's no technical reasons for precluding it from kernel development. Just like Rust, using C++ for driver development in Linux is a good place to start as well.
C++ is not used in Linux kernel development. Or B
Re: (Score:2)
As you say, Modern C++ allows for one to adopt the primary selling point of Rust: memory safety.
No, Modern C++ allows you to get most of the benefits, but not all, and only with additional effort and additional risk as compared to Rust.
Furthermore, because C++ has been around for ages, developers have access to a much higher breadth and depth of libraries and frameworks (e.g., Eigen for linear algebra).
Somewhat. Rust makes it very easy to call C libraries, and Google is sponsoring a project to make interoperability with C++ easy.
So, there does not really seem to be any particular advantage to using Rust.
I disagree with this completely. And note that I've been writing C++ for over 30 years and I'm actually very fond of the language.
Re: (Score:2)
Eigen for linear algebra
https://www.nalgebra.org/ [nalgebra.org], FYI.
Re: This is a good idea (Score:3)
Rust doesn't mandate it. There are ways to do unsafe things in rust. It only makes safety the default. That's not nothing but it's also not what was claimed.
Re: (Score:2)
Re: (Score:2)
"Most software development has already switched to managed languages that use run-time bounds checking and garbage collection to avoid huge numbers of pitfalls"
False.
"...so nearly all application development has moved to them."
Only a small fraction of "software development" is "application development".
"If you do low-level microcontroller development, OS development, game engine development, etc., you should give Rust a serious look."
Matching the tools to suit the job is what you should always do. Dependin
Re: (Score:2)
Matching the tools to suit the job is what you should always do. Depending on the job, Rust may be of no benefit at all.
But the poster is not advocating switching to Rust blindly. The suggestion is to determine if Rust is suitable for their use cases. Maybe it is not. Maybe it is.
Re: (Score:2)
"Most software development has already switched to managed languages that use run-time bounds checking and garbage collection to avoid huge numbers of pitfalls"
False.
"...so nearly all application development has moved to them."
Only a small fraction of "software development" is "application development".
No. Most software development is at the application level, not the system level, or on bare metal (though this latter category is a lot bigger than most realize). And my statement that most application development has moved to managed languages is correct. The data is easy to find.
"If you do low-level microcontroller development, OS development, game engine development, etc., you should give Rust a serious look."
Matching the tools to suit the job is what you should always do.
This statement is nearly a tautology, but I find that most of the time it's stated like this, it's an excuse for not actually using the tool best suited to the job, but instead to use the tool the speaker prefers. In particular,
Re: (Score:2)
Only a small fraction of "software development" is "application development".
I don't think this is correct. I couldn't find a root source for the statistic, but I found many websites claiming about 85% of software development is enterprise application development.
Re: (Score:2)
Pretty much in agreement. A lot of Rust's syntax makes me want to gouge my eyes out; but that's something you eventually get over, especially if you're young. If I were in my 20s I'd be getting over it NOW because Rust or something like it is the future for systems programming.
There's no excuse for putting yourself in a situation where you could shoot your foot off, when you've got a language that protects you without compromising performance.
The real pity is that the C standard's committee dragged their
Re: (Score:2)
A lot of Rust's syntax makes me want to gouge my eyes out
thread_rng().gen::<[u8;32]>()
I mean, how could that possible be clearer? :^)
Re: (Score:2)
In LISP you'd just use tokenized keywords in the argument list. Almost nothing needs tight loops for massive number crunching.
Re: (Score:2)
I would propose creating a new standard body.. call it D or something.
Import all of C, and add the minimal changes necessary to close the most common problems.
Then add optional features to address the rest.
You can move a Lot faster if you don't need to have a large panel with committee meetings.
Re: (Score:2)
You'll need another name because D is taken [wikipedia.org]. I think you'll get some resistance if it's not standard C. Yes, the standards bodies are sssssssssllow, but there's that whole psychology of wanting something that's "stable", and has industry buy-in. Is there any way to *quickly* install heavy-hitters from big names and move quickly? I don't think so. It's the never ending tension between small startups and independent devs that can move fast like we need, and large companies that can endorse the ideas and
Re: This is a good idea (Score:3)
Might be a smaller step to start with a language that already supports some mark up for analysis directives and contracts, such as Ada. We can call the new safety and formala analysis extensions something snappy, like SPARK.
Re: (Score:2)
There will be slashdotters who argue that unsafe languages are perfectly fine, you just need to hire competent programmers. They're idiots. Well, that's not really fair; they're not so much idiots as people who don't want to learn something else trying to defend their skillset. But if there's one thing we've thoroughly proven in software development over the last few decades it's that even the most competent programmers make mistakes. This shouldn't surprise anyone -- we're human! But this is why we build tools to help us.
Most software development has already switched to managed languages that use run-time bounds checking and garbage collection to avoid huge numbers of pitfalls. These languages are more efficient with developer time, which is far more valuable in most cases than machine time, so nearly all application development has moved to them. Javascript, Java, C#, Python, Go, etc.
But some software, especially system software, really does need higher performance and more predictable execution times than you can get with managed languages with GC. Until recently, Modern C++ (C++ that relies heavily on RAII, eschews naked pointers almost entirely, etc.) has been our best option for writing high-performance, tight code with minimal risk of serious memory management mistakes or bounds errors. It still requires discipline, because you have to follow the Modern C++ guidelines. Tooling can help to detect when you stray from them.
Rust is, I think, a better solution for this context.
I write security-critical code, code that uses cryptography to bootstrap core security features for the world's most popular consumer operating system (Android). We've been experimenting with and using Rust for the last 3-4 years, and it's just plain better. Once engineers learn the language well, they get stuff done as fast or faster than with C++ (which is in turn much more efficient in terms of developer time than C), and there are far fewer bugs. Obviously there are basically no memory bugs or integer overflow bugs, and Rust also helps to avoid some concurrency bugs. We're using it both in "big system" configurations (Linux, i.e. normal Android) and in tiny embedded environments, such as in the Titan M secure element. The latter is more difficult, because many of the libraries aren't available in "noalloc" configurations ("noalloc" means no heap, basically; all memory allocation is static), but it's getting better and is actually somewhat easier to work with than C++ in very constrained environments.
If you do low-level microcontroller development, OS development, game engine development, etc., you should give Rust a serious look. If you do application development you should use a managed language.
I won't argue that this isn't a good idea in concept. I'd only argue that the government has as much right to tell us what programming language to use as they do what we eat and drink. They can recommend this, and that's all fine and dandy. But the nature of our government today means some idiot up the chain is going to think this needs to be legally mandated, and even the study of existing languages or "historical" languages will end up being somehow an attack on the state. "If we let the C programs exists
Re:This is a good idea (Score:4, Insightful)
Most software development has already switched to move fast and break things development cycles and shipping Alpha quality software to ensure record profits quarter over quarter. These development methods are more efficient with shareholder value, which is far more valuable in most cases than the well being of societies that depend on them, so nearly all application development has moved to them. Microsoft, Google, Apple, Meta, etc.
But some software, especially system software, really does need a proper development cycle that can weed out security bugs and test for regressions. Proper coding can be achieved but it requires dedication, time, and discipline, because you have to resist the urge to release first and patch later. Proper management can help to reinforce this when you stray from it.
Proper market incentives and legal requirements are, I think, a better solution for this context.
I write code as a hobby, code that under no circumstances would I consider fit for widespread use in production environments without a thorough audit, and it's just plain better. Once companies learn to actually audit their systems and software, they will get stuff done as secure or more securely than with laze-fair development practices, and there are far fewer exploitable vulnerabilities and unnecessary code bloat. Obviously there are basically no importing entire sets of libraries for a single one-liner statement, and audits help to avoid those bone-headed default password problems. We also don't have to completely deprecate the use of an entire computing concept because some random buffoon decided we couldn't use it properly and thus needed to be forbidden from touching it to save ourselves. (Seriously, noalloc? You do...No, you don't. You just want to cling to the current fad and don't care at all about why your noalloc solution just means some hacker is going to use a different opcode to do the same thing before implementing their own memory management if they so desire....)
If you do any programming at all, you should give proper critique and audits a serious look. If you want to be handheld through your programming, you should hire someone else to do it for you.
memory-safe with at least partial proofs (Score:2)
https://cacm.acm.org/magazines... [acm.org] Note the discussion on how they handle recursive structures, adopting an approach from Rust.
Memory safety is of diminished concern (Score:2)
Re: (Score:2)
"Just that exploiting a buffer overflow in anything other than kernel code is pretty challenging..."
Particularly when the code has no buffers to overflow, for example. Throughout my career I have worked on few projects even conceptually vulnerable to memory safety issues. Memory safety is an interest topic for a relatively small subset of computer programming. A highly visible subset that so many thinks is all there is.
Re: (Score:2)
In situations where one needs to use a very low-level language (think firmware, OS kernels, et cetera), a subset of C++ is used with very few exploitable memory safety issues.
Which OS kernels use C++? Linux, BSD, Windows, etc. all use C and some assembly. Programming for the OS can use C++ but the kernel itself is not written in C++.
Re: (Score:2)
If you want dynamic allocation, there isn't really an accepted "subset" I can see. The C++ core guidelines are too generic to give guarantees (Bjarne doesn't even like subsetting and certainly not dialects which abandon backwards compatibility and the standard library, which is what is truly needed) and say SaferCPlusPlus is not exactly an industry standard.
Relying on ASLR/etc is basically assuming no iOS/Android level exploiters ever look at your code for a couple minutes. If Apple and Google can't keep co
Wouldn't it be better at the OS level? (Score:2)
That's Rich (Score:5, Funny)
Lisp (Score:5, Funny)
Why do you people keep avoiding lisp for the past 60 years like the plague?
Re: (Score:3)
Having had to write a program or two in LISP in college, long, long ago, I was glad I got them to work and I'd never have to write in LISP again.
Re: (Score:3)
Lisp is like entering the AST directly in to the compiler. Some problems map well to that; but a lot don't. Pure functional programming (I know Lips isn't necessarily like that, but it encourages it) also corresponds poorly to a lot of real world situations. Game devs love C++ for this reason--the object life cycle maps really well to things like a monster spawning, interacting with other entities, and getting destroyed. In theory you could shoe-horn that in to a parenthesis delimited AST. It's just a
Re: (Score:2)
Why do you people keep avoiding lisp for the past 60 years like the plague?
LISP is fine. I write elisp daily for small tasks. But it hasn't proven to be a very good language for most application spaces. The modern managed languages are easier to work with and provide the same benefits. And LISP is definitely not an alternative to Rust; among other issues, LISP basically requires GC.
Re: (Score:3)
Why do you people keep avoiding lisp for the past 60 years like the plague?
I had the prolog vaccination.
Re: (Score:3)
Lots of Irritating Single Parentheses.
A far better language for many use cases is TCL/Tk.
Can ChatGPT be trained to spot security problems? (Score:2)
If we can get ChatGPT to spot security problems, couldn't we run it against all our code bases and eliminate a lot of the issues?
Seems like a very powerful tool for discovering/fixing that kind of thing. If it can be done.
--PM
Re: (Score:3)
It sure as hell knows how to create them, and memory leaks. For fun I had it generate some really boilerplate C++ code and spent the weekend debugging it.
You will pry C from my cold dead hands! (Score:2)
I will contact my congresstwat and demand he stop Brandon from taking my compiler. Honestly he will eat that shit right up.
Re: (Score:2)
And while everyone's distracted.. (Score:2)
..by the turf war of the programming languages, the rubber hose exploitation team is merrily going about its business.
Wrong urge (Score:3)
How about "Urge tech companies to stop squeezing coders until nobody skilled is willing to write code"?
That's where the real problem lies. It always comes down to management. Sometimes there's a long lag, but it always goes back there.
Re: (Score:3)
Re:Politicians meddling in yet more stuff... (Score:5, Informative)
... they know precisely fuck all about. Probably some intern who once did a 2 month web dev course and had vaguely heard of buffer overruns mentioned it in the canteen one day to some policy wonk who was looking for another angle to pitch to the bosses.
I'm pretty sure that Linux, Apple, Google, Microsoft, Amazon, etc. all using Rust is not driven by interns at those organizations.
Yes memory safety is important , but at a certain low level you can't have it if you want to do anything useful hence even Rust allows memory unsafe blocks.
Yes it does but I am pretty sure that code reviewers would question any Rust code that explicitly allow for memory unsafe blocks. "So Bob, why are all these blocks of code marked with unsafe{}?"
I wonder if the politicians know what language their Windows/Mac/Linux kernel is written in?
Currently mainly C. However Microsoft has publicly acknowledge using Rust in parts of the Windows kernel development right now. Apple is far more secretive but them using Rust in certain cases is not earth shattering news.
Actually they'll simply think a kernel is something to do with corn so forget it.
So why do you think that the Office of the National Cyber Director knows nothing about computer programming? I am pretty sure the agency tasked with cyber security understands how computers work.
Re: (Score:2)
... they know precisely fuck all about. Probably some intern who once did a 2 month web dev course and had vaguely heard of buffer overruns mentioned it in the canteen one day to some policy wonk who was looking for another angle to pitch to the bosses.
I'm pretty sure that Linux, Apple, Google, Microsoft, Amazon, etc. all using Rust is not driven by interns at those organizations.
Yeah, toolchain decisions at Google are definitely not driven by interns. It's likely that interns did some of the initial experimentation with Rust, though, at the direction of the experience engineers managing them. Interns at Google are often tasked with doing experimental, exploratory work that the full-timers would love to do but can't justify. But moving beyond that to building the toolchains and integrating them into the build tools, code management and search systems, continuous integration systems,
Re: (Score:2)
The rule at Google is that all unsafe blocks require an extra layer of code review by the Rust team, in addition to the regular code review. I believe the code review tools detect and enforce this, though I'm not sure because I've never needed to write any unsafe blocks. 95% of the time when you think you need an unsafe block, you actually just need to rethink your solution. The other 5% is very real, of course, but most of it is when calling libraries written in other languages. It's pretty rare that you actually need an unsafe block in pure Rust code.
Most of what I have seen is unsafe{} works to bypass temporary roadblocks in development. However, the code should be made safe eventually before that code goes into production or there has to be a justification why it can not be made safe.
Re: (Score:2)
So why do you think that the Office of the National Cyber Director knows nothing about computer programming? I am pretty sure the agency tasked with cyber security understands how computers work.
I don't disagree with anything you wrote... except maybe for this. With any of these high-level federal appointments, politics plays a significant role. Rudy Giuliani demonstrably knows very little about computers, yet he ran a cyber security company and was the security point man for an earlier Trump campaign. It's not hard to imagine that the ONCD could be headed by someone who knows jack squat about security - which means they could choose to pad out the office with other know-nothings, if they chose.
Re: (Score:2)
It's not hard to imagine that the ONCD could be headed by someone who knows jack squat about security - which means they could choose to pad out the office with other know-nothings, if they chose.
The recommendation comes from the agency and not the director himself. As for the director, Commander Harry Coker, Jr [wikipedia.org] US Navy (retired) has worked in technology roles at both the CIA and NSA. I guess he knows something about computers.
Re:What is with the "Rust" propaganda? (Score:5, Insightful)
It's unusual in that it's safe by default (C++ can be written mostly safe, but people screw it up all the time), and not just on memory. When you first learn it, it's a bit of a pain, because you're used to C-like languages letting integers auto-promote and narrow, types copy and convert to references implicitly, etc. and it's usually what you want, until it's not. Rust's integer types don't promote or narrow without explicit intervention, and at least in debug mode, they don't overflow silently. And unlike other languages that provide memory safety guarantees like this, Rust provides many of them as compile-time guarantees, with no runtime checks required, so performance isn't impacted.
It's performant-by-default in other ways as well; in C++, it's very easy to inadvertently do the inefficient thing (e.g. copying a large vector to pass it to a function, rather than moving it, even if the caller never needs the vector again). Rust's defaults are basically always the performant option, and you have to explicitly opt-in to less efficient code (e.g. if you really want to copy something, you have to call the copy or clone method, otherwise you move it and ownership is transferred away; if you're passing a reference to a value, you pass it explicitly, and explicitly specify mutability at the caller side, you don't have to track down the function being called manually to verify if it's accepting by value, reference or const reference like you do in C++).
Those ownership semantics that improve performance also happen to make it a lot easier to write threaded code; you can't share a mutable reference to data by accident (you can have a single mutable reference to data, or many immutable references, but the compiler blocks having both) unless it's an indirect sort of thing designed for the purpose (mutex or atomic protected types that are protected against unsafe simultaneous mutation by multiple threads).
There are a lot of languages that offer one or two such features; memory-safe languages are pretty common now. But most of them are a lot slower (e.g. Python, Java). Or a lot less type-safe (JavaScript is one of the worst, but almost nothing is as type-strict/safe as Rust). Or the guarantees are largely enforced at runtime (making safe code a compromise that also slows it), and/or easily bypassed by accident (e.g. C++)
I've been programming C & C++ for a couple decades now, along with Perl (admittedly less Perl nowadays), Python, JavaScript, and half a dozen other languages when a project calls for it. Rust is a royal pain in the ass to learn in the first place (I'm still learning it, only written a few small projects in it over the last few months), simply because most people are used to languages that aren't so strict, but it holds the unusual distinction of being the only language I've worked in where, once my code compiles, it's always been correct. I'm good enough to get the high-level logic correct on the first try, and the rare (less rare when learning) mistakes I make in other languages are rejected by the compiler (so far) 100% of the time. I've yet to have a single runtime bug in Rust AFAICT; I expect I will eventually, but I've never written code in a new language for months like this without encountering trivial off-by-one errors, out-of-bounds issues, type incompatibilities, range issues, lurking undefined behavior issues, etc. Rust is unique on that metric, and given how little I trust other programmers to not suck at their jobs, I'd much rather they use a language that prevents the footguns than trust them to maintain the discipline required to make some other similarly performant language achieve the same results.