The world seems so loopy. But at least someone's written a memory-safe sudo in Rust

The sudo command-line tool has been implemented in the Rust programming language to hopefully rid it of any exploitable memory-safety bugs. Prossimo, a project overseen by the non-profit Internet Security Research Group (ISRG), announced the first stable release of sudo-rs this week. That open source codebase includes the …

[StrangerHereMyself]

Mandate

How long before the U.S. government mandates that all its software be written in a secure programming language? I mean, Java has been available for almost 30 years and C# for more than 20.

If Microsoft and Sun had compiled C# and Java native code instead of a virtual machine I believe there would be little demand for a language like Rust. Alas, that ship has sailed and during the last two decades many people have attempted to modify or add extensions to C / C++ or came up with newer languages to make systems programming safer. None of those really solved the problem or took off. Rust is the only effort that seems to have a substantial following

[F. Frederick Skitty]

Re: Mandate

Full disclosure: I used to code extensively in C and C++, currently in Java, and I'm learning Rust.

The trouble with Java and C# is that they use garbage collection, and if that was retained as part of the runtime support for a natively compiled implementation, then it has important implications for performance. It also impacts the ability to do anything approaching real time work with them. There are a few Java implementations that target embedded devices, but they tend to insist on some very strict limitations on how and when objects are created.

I'm a bit ambivalent about Rust right now. It's just a bit too different in a number of areas from what I've used before, not just in it's memory management features. There again, that may be more of a reflection of how thick I am, and it still feels a lot simpler than many C++ features - particularly the template metaprogramming that was all the rage a few years ago.

[StrangerHereMyself]

Re: Mandate

I program in aforementioned languages too (replace Java with C# in my case) and I can tell you that garbage collection latency is not an issue in MOST cases, especially ones where things happen on human time-scales.

Rust was only invented for performance critical and systems programming, although just like C/C++ more and more people are using it for general purpose programming.

[werdsmith]

Re: Mandate

I am really enjoying getting into rust, now but the one thing that annoys me is the need to be online, the method to have all crates that you might need (all of them) available offline is ropey.

[karlkarl]

Re: Mandate

Agreed. This kind of culture for dragging in technical debt (aka NPM, PIP, CPAN, crates.io, etc) is problematic.

I feel it comes from the fact that the entire computing platform is C and that bindings and bindings generators for any other non-C based language are not perfect; thus these package stores arise.

I think either a semi-C superset, or bolting a C compiler onto a language is the route to go in the long term. C++ is a (close) superset of C and its success and popularity possibly reflects this.

[fg_swe]

Or

...maybe because it makes economic sense to reuse basic libraries such as buffered TCPIP, buffered Files, http requests, PDF Parser?

Real World C++ programs will use dozens of foss libraries, too. They are just managed via yum or apt-get, instead of npm or rust crates.

Of course they all have Bugs of their own, more or less capable maintainers etc. They must be correctly used, which can be a challenge.

Still no difference between C, C++, Rust, Java, TypeScript or Sappeur.

Libraries exist for fundamental reuse economics.

[that one in the corner]

Re: Or

Huh?

You do not need to invent something like "crates" to get all the benefits of libraries (and, yes, we *know* libraries exist for reuse, that is the only reason they exist for).

> Still no difference between C, C++, Rust, Java, TypeScript or Sappeur.

You do know that libraries predate C, let alone C++? And even C++ predates things like yum and apt-get?

Rust can not be used (except possibly trivially) without getting involved in crates - C/C++, Pascal, Modula2, Fortran all coped admirably without even yum, let alone apt-get. And still (can) do - one of their great advantages is that you get to determine what level of control you exercise (hopefully total control, being able to build all of the components of your product from locally held assets pulled from a specific version control tag, but, hey, each to their own).

Java has less control, but not so much at the build end (don't get me started on Java run times on User machines!).

Typescript - haven't used it, so I'll talk about JavaScript, the thing it compiles to IIRC: you do not *need* to use npm to use Javascript. People do, far too much. That is the problem. You can use JavaScript (and probably TypeScript) without uncontrolled library usage.

Sappeur - who gives a damn?

PS:

PDF parsing as a "basic" library?

[FIA]

Re: Or

You do not need to invent something like "crates" to get all the benefits of libraries (and, yes, we *know* libraries exist for reuse, that is the only reason they exist for).

You've got it backwards. You need libraries for the benefits of something like crates. (Centralised artefact control, version/dependency management, etc etc).

Rust can not be used (except possibly trivially) without getting involved in crates

You're suggesting a language designed in the 21st century shouldn't learn any lessons from what went before? (Hell, the rust compiler seems to have a library directory, so I expect you could just put all the right libs in the right folders and it would all work. You could probably even write a Makefile to do this too).

C/C++, Pascal, Modula2, Fortran all coped admirably without even yum, let alone apt-get.

I work with Pascal daily, and have worked with C (and a little C++) through the years. They don't cope admirably. Dependency resolution can be a right PITA. (We have a folder full of all the delphi libraries we use, and a very long include directive developers just end up pasting into their IDE settings.)

I also worked with Java in the pre maven/gradle days and that was usually half a day to set up a new developer in Eclipse... making sure they had all the right libraries in the right place, etc. etc.

And still (can) do - one of their great advantages is that you get to determine what level of control you exercise (hopefully total control, being able to build all of the components of your product from locally held assets pulled from a specific version control tag, but, hey, each to their own).

You can do this with rust too?? In fact that's the point of the various dependency resolution solutions... you can have a centralised, controlled repository, with only versions of libraries you know are bug free, and mandate that no external dependencies are used. (By simply not making them accessible from your CI/CD pipeline).

Java has less control, but not so much at the build end (don't get me started on Java run times on User machines!).

Java has the (old) maven and gradle, both fairly good examples of this. IIRC Maven was one of the first widely used examples of this kind of dependency management system. Gradle made it less XMLy. :D

(If you have a JDK, in theory download a java project, run the gradlew.bat that came with it, and you should be good to go).

Typescript - haven't used it, so I'll talk about JavaScript, the thing it compiles to IIRC: you do not *need* to use npm to use Javascript. People do, far too much. That is the problem. You can use JavaScript (and probably TypeScript) without uncontrolled library usage.

Exactly, that's the problem, people use the tooling badly, because they're either lazy, uneducated, rushed or simply don't care.

The problems these systems solve are real, and used correctly these systems can help significantly.

Don't confuse people using tools badly with bad tools.

[that one in the corner]

Re: Or

> You've got it backwards. You need libraries for the benefits of something like crates. (Centralised artefact control, version/dependency management, etc etc).

You do not need to invent yet another thing like crates to provide that functionality - it already exists elsewhere and has done for a long time. All you are doing with crates is re-inventing the wheel and needlessly tying it into one specific programming language.

> You're suggesting a language designed in the 21st century shouldn't learn any lessons from what went before?

I'm suggesting that those features you list are NOTHING WHATSOEVER TO DO WITH *A* PROGRAMMING LANGUAGE and should not be tied into one.

In the 21st Centrury you should be using an entire environment, which caters for multiple programming languages, to gain all those features.

An actual language, in the 21st Century, should have realised that it is *NOT* the centre of the entire universe and there are many projects that use multiple languages (making a suitable choice for each portion of the project). If the new language really, really tries to push its own version of "crates" then it is either totally unaware of what has gone before (it has itself failed to learn) *or* it is deliberately making it difficult to introduce itself into a non-trivial project.

> They don't cope admirably. Dependency resolution can be a right PITA. (We have a folder full of all the delphi libraries we use, and a very long include directive developers just end up pasting into their IDE settings.)

It is not the job of the language to deal with those things. You have pointed out that all those good, well-tried-and-tested were, to you, a PITA. That is because you had not bothered to look for any tooling to help you - which is why you so like crates, as it has been dropped into your lap without your bothering to do any work.

I work with multiple languages across multiple platforms (host and target) and yet find dependencies really quite easy to handle. How? I have a Build Environment[1] (currently, built upon Gnu Make with a couple of extra little tools) - I list the libraries that I want to *explicitly* use and the Build sorts out all the dependencies, complains if it can't be done, and pulls it all neatly together. Similarly, I have a working version control setup. So on and so forth. None of this setup favours anything over anything else.

[1] I keep thinking I ought to write this up and publish it, that would make it so much easier to point to real examples, but so many more fun thingss to do.

>> Java has less control, but not so much at the build end

> Java has the (old) maven and gradle,

I explicitly say *not* at the build end - and all you can do is talk about the build end? BTW, mentioning yet more tools that are targeting one language (Java) over anything else, making realistic non-trivial projects a PITA.

> Exactly, that's the problem, people use the tooling badly, because they're either lazy, uneducated, rushed or simply don't care.

Yes, yes, absolutely. Which is why I am surprised at you supporting the tight connection (that people are pushing) between Rust and crates, when, after all your education and time spent on looking at the tools already available and working.

> Don't confuse people using tools badly with bad tools.

Huh? I thought I'd been yapping on (and on and on) about the fact that there are perfectly good tools out there! And bemoaning that people don't want to use them (harping back to an earlier comment of mine: people - put non-trivial configuration files under version control, please!).

[chololennon]

Re: Or

> Still no difference between C, C++, Rust, Java, TypeScript or Sappeur.

OMG! you again with your (not so hidden) advertising.

[Daniel Pfeiffer]

You do not need to be online

Of course, if you want to stand on the shoulders of giants, you have to get their libraries onto your build-host. And there are various ways to accomplish that:

✅ Specify them as dependencies to cargo, which will fetch them. Easy, and needs online access only when dependencies change. Thereafter you can "cargo --offline build"

✅ Use a proxy like Artifactory to shield you from the internet. Still online, but not directly and again limited as in the 1st scenario

✅ If you mirror the dependencies in your LAN, give the URL as a dependency

✅ If you mirror the dependencies on your disk, give the path as a dependency

[fg_swe]

C++ Template Worshipping

99% of template use cases can be realized by an equivalent, simple m4 macro, which expands each instantiation to disk.

Then you get sane error messages from those files.

For all other useful cases of compile-time code Generation, please create small C, Perl,C++ program and include them into the make file.

Avoid templates, they are an insane way of generics and compile time calculation. Similar to BRAINFUCK.

[that one in the corner]

Re: C++ Template Worshipping

> 99% of template use cases can be realized by an equivalent, simple m4 macro, which expands each instantiation to disk.

Citation?

[fg_swe]

Containers, Smart Pointers

The vast majority of template use cases are simple things such as std::vector or shared_ptr. To instantiate them, simple search-replace is sufficient.

I have seen large (dozens millions loc) C++ based systems using the good old C macro processor for These generics. It Was the leading CAD system then, used to design cars and large aircraft.

[Claptrap314]

Re: C++ Template Worshipping

m4 is Turing complete (and someone got a master's degree building it that way). QED.

[fg_swe]

Re: C++ Template Worshipping

Use the simple m4 features. Essentially just the replace mechanics.

[Claptrap314]

Re: C++ Template Worshipping

You mean like replace the quote characters with something that doesn`''t show up everywhere in your document?

m4 is explicitly Turning complete. Period.

[jake]

Re: C++ Template Worshipping

I once wrote a C compiler in M4, just to prove to myself that it could be done. Learned a lot about both C and M4 in the process. As a personal learning tool, it was inimitable. Normally, I'd say "recommended" here, but I don't. Not really. While the silly thing works just fine (if slowly), there is absolutely no need for it in the great scheme of things.

[Anonymous Coward]

Re: C++ Template Worshipping

Bjarne Stroustroup writes at length in his books on C++ considerable diatribe against the use of macros! Though I also agree that the use of templates has a similar suite of issues.

Library-based programming in general has gotten a lot worse because of dependency hell. It wasn't so bad when you called on half a dozen libraries at most.

[fg_swe]

Re: C++ Template Worshipping

In most cases, templates are the same as a macro. Therefore, expand the macro to disk and have a look at them. Also during debuging!

[that one in the corner]

Re: C++ Template Worshipping

> Also during debuging!

Once more: Huh?

Using a template (a competent) C++ debugger will sshow you the code as you wrote it and let you step into and through the template, just as it will a non-templated function.

During debugging, if you are using a m4 as you suggest, then you are not even debugging the code as you wrote it (although you can, of course, step through the macro's expansion - in fact, you have no choice about that as the debugger can't see any "step over" point.

Oh, and templated code can be compiled as a series of functions, once per argument type (set of types) which are then just invoked as normal functions; macros are expanded in-line every single time. One of the reasons for templates was to get rid of the code bloat that macros can introduce (early examples of template usage generally being about implementing type-safe lists and other pointer-oriented fun, which end up being expanded many, many times!).

[fg_swe]

Yes

I do indeed suggest to compile and debug in the instantiated, on disk, code.

The "bloat" is not relevant for my projects and modern hardware.

[Claptrap314]

Re: C++ Template Worshipping

Well, he would, wouldn't he?

Oh, wait, the first C++ interpreters consisted of C macros, didn't they? Methinks he protests too much.

C++ was an abomination from it's inception. If you want an OO language, create an OO language. If you try to wrap a procedural language, you're going to create a Shoggoth and drive people using it mad. Just don't.

[abend0c4]

Re: Mandate

There is some considerable progress on ahead of time native compilation of .NET applications.

However, there's a danger of comparing apples and oranges. Unlike Rust, .NET relies quite heavily on reflection (the ability to retrieve information about objects, types, interfaces and their attributes at runtime) and a lot of popular .NET techologies (like Entity Framework and ASP.NET) use it to wire everything up at runtime. This means that a "typical" .NET program is carrying more baggage in the runtime, which as the present goal is for all the code you need to be in the single executable file can make it quite big. There's also presently no GUI support.

However, you ought to be able to write command-line utilities in .NET Native now that are roughly comparable to something you might write in Rust.

[StrangerHereMyself]

Re: Mandate

If Microsoft had taken into account native compilation for C# this wouldn't have happened. They blindly copied Java and didn't see C# as a replacement for C and C++ (Microsoft was and still is a C++ stronghold).

The world would look completely different if they had. There wouldn't have been such a strong case for Rust, since manual memory management is a standard feature in C#, but one which no one uses. You can mix and match it with garbage collection, which is a much programmer friendlier solution than Rust. Although Rust has some modern constructs like monads and Typed structs.

[abend0c4]

Re: Mandate

I think the problem is that there is a lot of stuff that's really significantly made easier by having a lot of the information around at runtime that a traditional compiler would just throw away. And I don't imagine Microsoft thought of having a shared runtime around was likely to be an obstacle: it would simply be present in Windows by default. It's only the growing world outside of Windows that's negated the original assumptions (and the number of incompatible versions....).

It probably would have been better in hindsight to have a clear subset of language features to support traditional compilation. Certainly, the current situation in which there's a list of stuff that's not supported or won't work as expected isn't ideal and isn't an incentive to adoption.

[StrangerHereMyself]

Re: Mandate

The requirement for a specific (!) runtime version is extremely bothersome and the main reason why I ported some of my C# programs to C++ and Rust. Also, the startup times for .NET plus the bloated memory and disk space requirements are a hobble for smaller systems.

[werdsmith]

Re: Mandate

Rust uses a runtime for somethings, like async functions.

[StrangerHereMyself]

Re: Mandate

Also, Microsoft's effort on AOT compilation is too little, too late. They've been working on it for years and years and it still only compiles a small subset of .NET programs. And even then with many caveats.

[fg_swe]

Re: Mandate

The Sappeur language is as close to C++ as possible while memory safe. Key C++, concepts are retained.

[Anonymous Coward]

Re: Mandate

> How long before the U.S. government mandates that all its software be written in

As soon as ADA conversion is complete ;)

[StrangerHereMyself]

Re: Mandate

ADA was by no means a bad choice 30 odd years ago. It, however, lacked mainstream support because OO and C++ were the hotties of the day.

Besides, ADA isn't memory safe by any standard. It's merely an amalgamation of C / C++ / COBOL and Java.

[fg_swe]

SPARK ADa

They claim to be memory safe.

[fg_swe]

Jäger 90

Apparently the safest fighter aircraft uses Spark Ada. Up to now no loss of aircraft due t o flight control system.

Everybody else had catastrophic losses: F22, F35, Gripen, Su27,...

[StrangerHereMyself]

Re: SPARK ADa

They have runtime checks, but these can be turned off. Memory safety isn't an integral part of the language itself.

[that one in the corner]

Re: SPARK ADa

True, you can switch off the Ada runtime checks (for very good, pragmatic reasons - aka 1980 computers, let alone the ones you could fit into anything mobile).

But there is a solid argument, when looking at a program, that you take into account its build system (its entire build environment) if you are actually concerned about the safety and security of the running system.

If you build spec states - and enforces (via your build system) - that the runtime checks that Ada defines are to be enabled, then they *are* present and can be relied upon as much as any other languages: any attempts by those naughty programmes to get around them (deliberately or not) will be caught.

The Ada spec defines those checks as part of the language, your setup insists that the entire spec is in play.

Not to say that it isn't better to have such checks - or, more accurately, the locations where such checks are abandoned - be visible in the text of the sources that more of your programmers are actually reading (please, learn about your build systems as well).

[that one in the corner]

Re: Mandate

> ADA ... It's merely an amalgamation of C / C++ / COBOL and Java.

Ada[1] appeared in 1980

C++ appeared in the 1983-1985 timeframe (from cfront to The Book)

Java appeared in 1995

Ada was influenced more by Pascal/Modula than anything else.

Not clear what you think Ada took from COBOL - certainly not MODIFY!

> ADA isn't memory safe by any standard

Which standards are you measuring by? It doesn't support (void *) style trickery, it provides all the run-time checks against array bounds, it even allows for garbage collection (but AFAIK practical implementations don't provide it). You can use memory pools to control allocation at the level of different structs (to lapse into a C'ism) or finer.

And, unlike Rust, there is a specification for Ada - and you can even get it for free (unlike other languages, unbelievably: really, ISO?).

[1] note - only uses one uppercase letter; why do people insist on ALL CAPS when referring to Ada, Lua, Pascal - even Fortran gave up the last extra capital a long while back! But he managed to get Java correct.

[DS999]

Re: Mandate

Memory safety is only the tip of the iceberg for security. The Rust nuts ascribe near godlike powers to it to prevent security issues, when it only protects against one class of security issues.

It is as nutty as the Ada people were in the 80s when "design by contract" was supposed to be the solution to all the ills of the programming world.

If we ever get real 'AI' maybe it will be tractable for it to program in a language that is formally proven so there cannot be any security issues and everything you say the program should do it will do and nothing more. Then people will realize the hardest thing about programming is gathering requirements, and AI won't be able to help with that because until AI is the one doing all the "work" it'll still have to gather requirements from people - who don't know what they want they only know what they don't want. In hindsight only.

[StrangerHereMyself]

Re: Mandate

Well that class of security issues encompasses about 70 to 80% of the total and can lead to unintentional exposing of information or a complete takeover of your systems.

No computer language will prevent logical errors but I believe Rust is a huge step forward in systems and high-performance programming. You see, up until now development of critical performance code required unsafe programming languages such as C, C++ or assembly. With Rust you can have your cake and eat it.

[Anonymous Coward]

Re: Mandate

c# and java?

For real?

[fg_swe]

Java Bloat

Java typically needs at least 2x the RAM of an equivalent ARC Managed program. That is my experience with Sappeur.

This is easy to explain: for competitive runtime, GC cannot be run too offen. So Lots of garbage MUST accumulae.

[Ian Johnston]

Re: Mandate

How long before the U.S. government mandates that all its software be written in a secure programming language?

Minus thirty two years.

[Michael Wojcik]

Re: Mandate

Yeah. The FIPS 140 mandate has also gone well.

A part of "the U.S. government"¹ can, and often does, mandate all sorts of things. Compliance is generally poor, as any number of audits by various Inspectors General and the like keep finding, over and over.

Government agencies need to get things done. They're going to try to buy software that lets them get things done. Obeying mandates from on high regarding that software is pretty far down on the list.

¹The phrase "the U.S. government" isn't particularly meaningful. Even if we assume the writer means the Federal government, that's a huge, heterogeneous entity.

[Steve Davies 3]

Re: Mandate

Java is DOA here. Once the Feds get a look at the humongous licensing costs that Oracle will try to charge no one in their right mind would use Java or at least an Oracle JRE.

[fg_swe]

Really ?

Boeing is charging tge Feds much more than Oracle can ever do.

A bigger Problem is the lack of multithreading support in the type system. Java simply is outdated in some ways.

[Kevin McMurtrie]

Re: Mandate

You clearly haven't seen much code. SQL injection, command injection, constants used for salt and initialization vectors for encryption, hardcoded passwords, trivially predictable auth tokens, disabled host key verification, FTP, backdoors for integration tests, ... There must be a social media challenge to put all the OWASP Top Ten vulns into one project.

I also agree that modern C++ style prevents non-obvious memory bounds bugs.

[prandeamus]

Re: Mandate

"If Microsoft and Sun had compiled C# and Java native code instead of a virtual machine I believe there would be little demand for a language like Rust. "

I take your point, but feel obliged to point out that C# does have an ahead of time compiler, NGEN. And I believe it's been available since day 1. That said, I don't think you can claim that native code has quite the significance you think it has. Deferring the code generation with JIT has overheads, yes, but it's not intrinsically more or less memory-safe.

[fg_swe]

gcj of BOEHM

Is an AOT for Java. Still suffers most of the Problems of Java such as high RAM consumption, no RAII, freezing on GC, no complex Stack allocation etc.

[jonha]

LuaJIT v2.x

I used to do a lot of work with a JIT compiler for Lua. This thing could produce phenomenally fast native code *and* it had a powerful FFI (of course, this was not a memory-safe area, very much like unsafe for Rust). Alas, the garbage collector made it very hard to write code that guaranteed a certain performance. There were some tricks to mitigate this and Mike Pall, the author of LuaJIT, had plans for a better garbage collection implementation but these never materialised. Even today, to hack together a quick utility I am more likely to use LuaJIT than Python.

[fg_swe]

ARC

Semi-realtime GUI Performance is best achieved using ARC. In Sappeur, all pointers are ARC Smart Pointers.

[that one in the corner]

Re: ARC

Semi-sweet biscuit flavour is best achieved using dried fruit. In Garibaldis, all dried fruit are currants.

[Ace2]

Re: ARC

Do they come in Sappeur flavor? Whatever TG that is.

[Bebu]

Perhaps /etc/sudoers more of a problem than perhaps C memory safety

The syntax and semantics of sudo's configuration file(s) are not always entirely clear or obvious. I suspect more unintended access arises from misconfiguration than from memory safetly issues.

Still (re)writing privileged code in a memory safe language has to be applauded. A garbage collected language (Go?) would be fine for something like sudo, I would imagine.

[John Riddoch]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

Usually the issue arises with wildcards or command line options which do more than you expect as well as the better known shell escapes (like from vi). I know we had to put in a bunch of exceptions so that "/bin/cat /var/log/*" didn't blindly give access to any file on the system. However, it's possible to write safe sudoers rules, but you can't mitigate software bugs as easily.

[that one in the corner]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

> However, it's possible to write safe sudoers rules

It is possible to write safe C code as well. Just trickier than perhaps we'd like (you have to concentrate on what you're doing, unlike wildcards and regexs in configs - oh, wait...)

> but you can't mitigate software bugs as easily

(Bangs head on table) Configuration is also software. Configuration that is complex enough to be called "rules" is non-trivial software and suffers all the ills of its more discussed cousin. To the version control system with you!

In other words: if you are going to put in the effort to make sudo (or anything else) safe, then it is equally important to make sure its configuration is safe.[1]

After all, there are many, many more people writing configs than there are writing the things that read them, and, let us be honest, they are not all as well-trained in the Dark Arts as the latter.

But, yes, I take your (probable) point that the sudo (or whatever) executable is copied verbatim across many more machines than a duff config[2] so a flaw in it will require all of those machines to be updated - oh, except that nowadays disseminating software updates is actually pretty easy...

[1] yeah, I know, if we change the config then everyone has to update and they'll hate us for it, etc etc

[2] well, except for that duff example someone published on StackExchange...

[Spazturtle]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

"It is possible to write safe C code as well. "

The issue is that it is not possible to guarantee that C code is safe, given how many times memory issues have been found in critical c code written by experience coders.

[Michael Wojcik]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

The issue is that it is not possible to guarantee that C code is safe

It is not possible to guarantee any non-trivial program is safe, because "safe" is not well-defined and security is not an absolute.

The programmer's intentions may not match the user's intentions. The user's intentions may not match their desired result, or the result desired by the owners of whatever resources are affected. Everyone may have the correct intentions but there may be unanticipated adverse consequences.

Adding security mechanisms to a language – as Rust did, with its strict object-ownership rules – prunes branches off the attack tree and removes some failure modes. The same can broadly be said for using modern C++ idioms (though in significantly different ways and with significantly different results) versus C and C++. But these are quantitative differences, shifting some of the work of improving security from the programmer to the machine, not qualitative ones.

[James Anderson]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

You cannot write a device driver, a task schedular, or a memory manager in go, C# or Java. So they are not usable for low level operating system components. You are stuck with C, assembly code or Rust. You can just about use C++ if you ignore most of the language features.

[that one in the corner]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

> You can just about use C++ if you ignore most of the language features.

"Just about"? Huh? If you can do it in C you can do it in C++, no " just about" involved.

Don't get dragged into those stupid "if you aren't using Modern C++[1] then you aren't using C++ properly" twaddle. If there is no advantage to using someone's favourite library then don't use it, same as any language in any situation. If you can write "neater, safer C" just by encapsulating struct members into private class members with well-defined member functions, then you are using C++ properly. If it doesn't help to use virtual functions, don't use them - that is using C++ properly. If the task doesn'tbenefit from using Boost, don't use Boost. There are even other implementations of smart pointers, lusts, trees etc than STL - if they fit better, use that library: STL just a.n.other library after all.

Not using a facility that does not help your requirements is not "ignoring language features", it is understanding the language features - whichever language - and using it appropriately.

[1] which just boils down to "whatever is trendy today" :-(

[fg_swe]

simplistic

There are systemic reasons in the C and the C++ language, which make them memory Unsere. Regardless of library used.

Some of them listed here http://sappeur.ddnss.de/WhyCandCppCannotBeMemorySafe.html

[Anonymous Coward]

Re: simplistic

Way to ignore the point that was being discussed in the comment you replied to.

Again.

[fg_swe]

Mostly Wrong

See Algol mainframes, see Singularity. OS, see Modula 2.

Of course one needs judicious exceptions from memory safety for certain specific operations. My estimation is 1% of OS code needs to be unsafe. Thats much better than the 100% unsafe concept of Unix and Windows.

[Michael Wojcik]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

You cannot write a device driver, a task schedular, or a memory manager in go, C# or Java.

You most certainly can. At the limit, you can use the Kolmogorov-equivalency approach: You write an interpreter for the desired language in some language suitable for the target environment.

More generally, there's nothing that inherently prevents directly writing any of those three things in any of those three source languages, except possible ABI issues. Any of those languages could be compiled to native code, if that's a requirement of the environment (and such a requirement is itself arbitrary).

[abend0c4]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

I don't think it's contentious that delegating OS security to a highly-privileged application program which determines whether unprivileged users can execute specific other highly-privileged applications programs is not a great idea - and the additional risks largely flow from that and these various initiatives mitigate the risk but don't eliminate it.

Given that Linux is not short of security options - ACLs, capabilities, the various features used for containerisation (like namespaces), the LSM interface (used by AppArmor, SELinux, Smack - and indeed now to implement capabilities), it's worth considering why sudo even continues to exist - I hadn't really given it any serious thought until now.

A good example is one for which sudo is widely used: shutdown. If you compare Windows, there's a system call (OK, several system calls, but the principle holds) to shutdown the system and its use is restricted to those having the SE_SHUTDOWN_NAME privilege. However, there is no Linux equivalent system call: the kernel isn't responsible for system shutdown. The shutdown program itself is responsible for writing the shutdown message, writing the syslog message, signalling the init process and killing any remaining processes, disabling swap and unmounting filesystems. That means in order to do its job it needs not just a single permission but a whole slew of privileged rights that you would not want users to have outside the context of a shutdown event.

I can see both the history and the logic of this, but the greater the number of different places you have to define your security rules and the more complicated they are the greater the likelihood of error.

[abend0c4]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

I don't think it's contentious

Clearly I was wrong!

[cornetman]

Re: Perhaps /etc/sudoers more of a problem than perhaps C memory safety

I would be interesting in hearing how you would practically implement such a system.....

[b0llchit]

I think...

$ sudo make me a sandwich

...will fail when it is created with iron oxide.

[fg_swe]

Blood

Your body only works due to Ironi oxide inside the Red cells. The Ironi oxide Makes your blood Red, actually.

[fg_swe]

please disregard the Auto correction

Damn

[that one in the corner]

Re: Blood

Nope.

Your blood is red due to the presence of oxygen-carrying haemoglobin, where the oxygen molecule[1] is weakly, and reversibly, bound to an iron ion at the centre of the protein. The iron is in an oxidation state ('cos it is an ion in the protein molecule), either +2 or +3 (the latter when weakly bound to the oxygen molecule) and this then leads to the colour change to really lovely bright red (unlike the purpley red stuff the phlebotomist takes from you).

But the iron is NOT in the form of iron oxide.

No, not even that funky Fe25O32 oxide[2]. We probably be making weird crunching soumds if it were (well, and weird choking sounds).

[1] note: an entire molecule, although whilst being carried it does carry a charge and is therefore a "superoxide ion" - gets weird down there, they didn't tell us this in O-level chemistry!

[2] which, I'll be honest, I didn't know about - or its similarly fun-loving sibling Fe13O19 - until I looked up Fe oxidation states, 'cos I couldn't remember which was ferrous or ferric[3]! Then again, I did use Wikipedia and haven't followed the citations, so...

[3] I know, call myself a programmer, talking about spinning rust, and I can't even remember that.

[G40]

Can we please stop fetishising rust whilst conflating C++ with C?

Rust: an unwanted emission with poor tooling from a source with a dreadful record in good language design. Appalling choices from a syntactic perspective and an unknowable runtime. Should have done much better.

And C != C++. Writing code in the latter language is more simply saving your code with a.cpp extension. Indeed, this has been the case since the previous millennium.

[StrangerHereMyself]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

The drawback with C++ is its backwards compatibility with C. You can write 1970's style C code and compile it on a modern C++ compiler.

I always remind myself that C is merely "high-level assembly" and therefore has the same warts and dimples, i.e. no memory safety or bounds checking of any kind.

[that one in the corner]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

Agree with the low-level nature of C, that it does allow you to blow your foot off if you ask it to, but we are talking programming and if that isn't the place for pedantry - oops, I meant to say "precise usage" - what is? So...

> You can write 1970's style C code and compile it on a modern C++ compiler.

Can you?

C didn't allow the parameter type to be included in the argument list until C89 (formally - some implementations allowed it before then: most such changes get tried out by various implementations until they are codified in the standard).

In the 1970s you were listing the parameters to C functions in the argument list (well, duh) and only defining their type - if you could be bothered - between that and the function body.

Now, I'm nowhere near a compiler to verify this[1], but I'm pretty sure that the old-style argument list plus definitions will get rejected by your modern C++ compiler.

I have a sneaky suspicion there were a couple of other bits from the 70s that didn't transfer over as well (Stroustrup being compatible the C as it was implemented from the mid-80s). Anyone? There was a change in the namespaces for struct and typedef, but that would not lead to an incompatibility in this direction? Over to you.

[1] I feel sure I'll soon be corrected, go on, do your worst:

[abend0c4]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

The limitations of using gcc to compile K&R C are described here. So I'd say you were vindicated!

The notion that C++ has "backwards compatibility with C" is just plain wrong. I think in a very early version it actually compiled into C, but that's not been true for a very long time.

Its drawback (apart from its many versions), if anything, is its mysteriously random incompatibility with C.

[that one in the corner]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

C compatibility is a weird one nowadays. The best that can be said now is that you can write code that is compilable as both, but you have to prepared to grit your teeth and not do something that would be reflex if you stuck to one or the other. And then passing those fixes upstream ("but *why* are you compiling our nice C library as C++? Go away, you nutter!").

For the curious, I have little libraries that I use on MCUs (e.g. My Favourite Scheduler) and not all MCUs have (had?) a C++ compiler (only a few, but for some reason I got handed them) - worse, the C isn't likely to be up to the latest standard. So the libraries are built both ways, with comments reminding me not to "tidy up" this bit.

[Mishak]

1970's style C code

A conforming C++ implementation is not going to accept 70's code that uses any implicit declarations or "K&R" style functions, and the mess of pretending that int's are chars and bools is also gone (apart from some implicit contextual conversions to bool). It's a pity that integer promotion is still a think though.

[Michael Wojcik]

Re: 1970's style C code

It won't be happy with plenty of possible C99 or C11 source either, like anything that uses "new" or "class" as an identifier, for example. Or that uses implicit conversion of void* to a specific object pointer type (which is preferable over using a cast, in C, since the cast can hide various errors).

[fg_swe]

C and C++: Same Deficiencies

C and C++: are full of Undefined Behaviour in many aspects:

http://sappeur.ddnss.de/WhyCandCppCannotBeMemorySafe.html

[fg_swe]

Lameness

Five downvotes, no counter arguments. I take that as 5x5=25 upvotes.

[that one in the corner]

Re: Lameness

Sigh.

> Why C and C++ Cannot Be Memory Safe

If you are dragging C into this, you have either totally missed the point (C is entirely pragmatic about letting you shoot yourself in the foot, with good reasons, and nobody ever claims it will automagically stop you doing anything at all) or you know this and are going to talk about whether it is possible to write something that acts in a memory safe way (which it can, it will neither help nor hinder - you can code safely or you can code unsafely).

> The root cause are their type systems and established usage patterns.

Usage patterns are just that - patterns. They can, do and (especially for C++) have changed over time. You can not make any argument about capabilities of any system based upon usage patterns, especially not "it can never do X because I have so many examples of it not doing X".

Coca-cola can not be used for rehydration purposes because the only time I see it is to do that trick with Mentos[1].

Ooh, ooh: remember what I said before about "possible to write"? That is usage, so, yes, you *are* allowing for that to be taken into account! We win, you definitely *can* write safe code in C, and by extension, C++, you just have to use it right.

> Both C and C++ have no concept of "data only reachable by local thread" and "data reachable by many threads"

You really should stop going on about C - every time you mention now, you are only bolstering the case in its favour, as we all know what C claims to do or not.

With respect to C++: what you have just described is a "trait" and C++ has long allowed us (even before "trait" was used so often in STL to mean a fairly specific subset of the concept that someone will pull me up for "using the word") to use types to declare and define " stuff with traits" and then refuse to compile if you mix'n'match badly. Of course, you can decide to go outside those neatly set up declarations (e.g. use a.n.other library that does the same but with different words) and mess things up, but that is why we have coding guidelines - just the same as stopping you from dragging in yet another PDF parsing lubrary when we have one already).

> The C language would have to be extended in order to make all pointers Smart Pointers.

Deep sigh. The C language was modified to allow you to make all pointers smart pointers, it is called C++. Come on man, focus! Next you'll be having a go at Assembly!

> unsafe vector operations like ::std::vector::operator[]() are also a rich source of memory errors. Compilers should be able to report their use as errors.

You don't want anyone to use a specific method call from a specific library? JUST DELETE IT from your copy and the compiler will refuse to let you call it!

Etc etc. E.g. unsafe cast from int to pointer? Aside from "valid but oh how I wish it weren't" usage when dealing low-level stuff, use the C++ cast syntax and you can spot it a mile away. No whining that you can still write yucky C style casts, we have already established that you are allowing discussion of usage, good and bad.

****

Oh thank heavens, there is the call I was waiting for, I can stop just filling in time on a Sunday morning with this ineptly argued drivel from Frank. How I envy everyone else who didn't have to fill in a moment of "can't go and do anything more useful for the world".

****

[1] which is true, we love that trick - with Polos - but this is not a Coke Corner. Bad for the grass, though.

[fg_swe]

C and ++: Threading Defects

Both C and C++:have no strict mechanism to stop accidental sharing of a variable/object between threads. Identical Problem.

Also, no way to force use of safe Arrays in eiher language.

No way to detect and stop a stack overflow. Both.

No way to stop use of raw pointers. Both.

Etc.

[that one in the corner]

Re: C and ++: Threading Defects

Ye Gods.

So referring to C and C++ as one thing and claiming that C++ can't do something because C does!

It gives you absolutely no credence even if you do manage to make a reasonable statement about one or the other!

Gawd, no wonder everyone is getting fed up with you and you prattle about your Sappeur.

At least *try* to listen to criticism and take it on board if you really, honestly, think you have something of value to present: if you do then you surely want to present it in the best light, don't you?

Must go and find a book to read and step away from this.

And ... Breathe.

[fg_swe]

Re: C and ++: Threading Defects

You seem to be unwillig to look at my arguments. Facts are of no interest to you.

Science is not a beauty or rhetoric contrst.

[that one in the corner]

Re: C and ++: Threading Defects

You seem to be unwilling to present your arguments clearly. Constructive criticism is of no interest to you.

Science is not haranguing.

Beauty contest? There is beauty in the simple & clear, from hypothesis to law. Much science has come from looking at "the state of things" and seeing clutter, not beauty: I give you planetary epicycles and raise you the unifying of the weak and electric forces.

[Michael Wojcik]

Re: C and ++: Threading Defects

Engaging is a waste of your time. fg_swe is a longstanding Register forum kook, who shows up only to plug his pet language. We've seen these same arguments for years. They've become boring; he's not even a fun kook these days.

[jake]

Re: C and ++: Threading Defects

"a longstanding Register forum kook"

I dunno that I'd go as far as to call him a kook. Too much baggage with that. IMO, loon would be more accurate in this case.

Concur with the rest of yours, though.

[Doctor Syntax]

Re: Lameness

"Five downvotes, no counter arguments."

OK, let me give you some: you're trying too hard, being tiresome and still not explaining your own position.

[find users who cut cat tail]

Re: Lameness

Not sure what the numbers mean, but you clearly prefer quantity over quality in your posts. So have another one from me for spamming the discussion.

[Daniel Pfeiffer]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

Your 2nd point is valid, but irrelevant as both of those languages are unsafe. „You can do better in modern C++“ is optional and hence weak consolation.

Rust's cargo is delightful to work with and gets a lot done smoothly. Helper tool rustup makes it easy to keep it up-to-date and even have nightly in parallel, to try out proposed new features. The IDE language server rust-analyser works fast and well. Not sure what poor tooling you mean.

I don't know what „a source with a dreadful record in good language design“ refers to. But even if it's true, whatever their past failings may have been, for Rust they did a pretty good job. Of course its a matter of taste you may disagree with, but the syntax is fairly simple and consistent. And the concepts for eliminating data races, null pointer woes and memory abuse are elegant and powerful.

I don't have a fetish for Rust. But after years of looking open-mindedly at many languages, I finally feel at home.

[that one in the corner]

Re: Can we please stop fetishising rust whilst conflating C++ with C?

> Helper tool rustup makes it easy to keep it up-to-date and even have nightly in parallel, to try out proposed new features

That just adds to the feeling that using Rust is still building on shifting sands.

Note: I said "feeling" - glad to be proven wrong - but I like nice stable environments that I can keep repeatable.

[Arthur the cat]

Unix greybeard nitpick

Unix-like systems (eg: Linux and FreeBSD)

Unless you're a lawyer banging on about trademarks, FreeBSD is not Unix-like, it's Unix. There's a clear line back via the Berkley Software Distribution to the original Bell Labs code. Of course, it's all a bit Ship of Theseus these days.

[fg_swe]

Greybeard 2

Unix is clearly inferior to the Algol Mainframes of the 1970s.

E.g. ICL VME, UNISYS, MOSCOW

[fg_swe]

Re: Greybeard 2

(In terms of memory safety)

[Anonymous Coward]

Re: Greybeard 2

Explanation? Citation?

E.g. are you comparing the CVE reports for Linux against those for VME etc?

[fg_swe]

Re: Greybeard 2

The Algol mainframes are(on a high level) similar to Java virtual machines. Bounds Checking for each array is done by the CPU, for example. Pointers are guatanteed to be good or NULL etc. Numbers are Typed, too. You cannot add a pointer to a flott, for example.

This is also mostly true for Kernel/System Code

These Algol computrs look much more secure to me than the Unix "one lange array of untyped octets" approach. I do not have statistics, though.

Also Listen to Tony https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/

[Anonymous Coward]

Re: Greybeard 2

Got a reference for MOSCOW? So we know what you are referring to?

'Cos Unisys is a manufacturer, VME is an OS, MOSCOW is ???

[fg_swe]

MOSCOW

They now use the misleading Name MCST.

Read mcst.ru and the wiki Page.

A long time ago, they designed and built Algol Mainframes. They even have a metro Station of their own.

[Arthur the cat]

Re: Greybeard 2

Unix is clearly inferior to …

That very much depends on one's metric. Existence tends to beat most of them.

the Algol Mainframes of the 1970s

Pah! Mere latecomers! Burroughs stack machines existed in the 1960s.

However, simple fast RISC machines wiped the floor with complex architectures. It's just a Small Matter Of Programming to ensure the compilers are perfect(*). :-)

(*) I'm sure AI will let that happen(**).

(**) Anyone interpreting this as anything other than sarcasm needs remedial lessons in reality.

[fg_swe]

Performance BS

For a long time execution performance was the one and only metric. This brought the cyber war and cyber crime world.

Most computer people are cyclops ?

[Anonymous Coward]

Re: Performance BS

> Most computer people are cyclops ?

Well, that would explain why our users keep trying to sneak past hanging onto the underside of our sheep.

[jake]

Re: Greybeard 2

"Existence tends to beat most of them."

Longevity tends to beat the rest.

Compilers aren't perfect, and never will be ... although see "longevity", above.

[Anonymous Coward]

This all assumes...

.. that the rust compiler isn't buggy, and the third party libraries are also sound.

[fg_swe]

Experience

From my own language I can say that Compiler Bugs do exist but they are rarely the source of real-world defects.

Memory Safety is not the holy grail of Software engineering and it does not kill all Bugs and defects.

What it will do quite reliably is to detect the 70% of exploitable Bugs related to memory access.

A powerful aid to the Software engineer. Comparable to ABS for drivers.

[Mishak]

Re: Experience

In my experience, most C/C++ "compiler bugs" that I have been shown are a consequence of undefined behaviour within the code leading to invalid optimisation.

[Anonymous Coward]

Re: This all assumes...

This article assumes a lot, particularly insanity. Josh Aas (ass?) has the ramblings of a 1-year-old-vying-for-government-recognition... like a Carl Icahn of a newborn iT "project". Is shitting on the languages that have made modern computing a good business strategy? Must be for Josh Ass.

[fg_swe]

Re: This all assumes...

The only irrational guy here is YOU. No counterfacts, so you attack a man's Name.

Go back into your cave.

[ethindp]

If you want memory safe and secure software, use ada. Simple as that. Rust only offers memory safety; Ada and Spark offer that and, if you want, correctness and provability. Absolutely no contest. (And before anyone complains about the lack of libraries: that's because not many people use it; if more people used it, it'd get more libraries...)

[fg_swe]

Well

I agree that Ada looks like a very reliable language, if properly used.

You still need a proper engineering process such as rhe V Model to achieve good System quailty. You need proper, experienced engineers, Management and proper funding.

Such projects do exist, like the one I mentioned.

[ethindp]

Re: Well

Yes, Ada won't save you from your own stupidity. But Rust doesn't either. Literally all Rust did was reinvent a bit of Ada and call it something different.

[MTimC]

Rust. Lol.

Stroustrup ought to know about memory safety and strongly typed programming languages as he worked on the CAP computer, which had its operating system written in Algol68 for that reason, to show that you can use high level languages (as opposed to BCPL, its untyped competitor and precursor of C), and improved programmer performance).

[fg_swe]

Re: Rust. Lol.

Great comment, Thanks.

In defence of Mr Stroustrup it should be said that performance and general efficiency was long seen as the only objectives.

Life-critical computing(e.g. full authority flight control software) and cyber crime/war have been changing priorities.

[Anonymous Coward]

NP complete

First a nitpick - Thomas Claburn says "Most modern programming languages, in one way or another, allow developers to write code in a way that's memory safe". That's not fair. Even writing in assembly "allowed" programmers to write perfectly safe code, and it's only because the programmers chose to die of old age or suffer a brain aneurysm or other personal memory failure before finishing the job that it didn't work out.

It ought to be - "Programming languages which use garbage collection don't allow developers to write code in a way that's memory unsafe".

Rust doesn't qualify because you can switch off the memory checking -

unsafe

{

// TODO: brain aneurysm

}

There must be some good (or maybe even bad) reasons Linus Torvalds has shut down the idea of incorporating a garbage collecting language for kernel use for non-time critical operations - e.g., sudo. The discussion seems incomplete without hearing those reasons.

[fg_swe]

False

You dont know what you are talking about.

[fg_swe]

Re: False

Almost all Cpus have no concept of memory safety in a fine granular way. No concept of multithreading race condition avoidance.

No concept of automatic pointer initialisation.

The only exception might be the Algol mainframes, some Lisp machines and the iApx423. Only the algol machines are currently in production and sale.

Memory safety these days come from strong typing of a HLL and from compiler generated runtime checks.

[Anonymous Coward]

Re: False

I stick by my point - for example in JS (or any other language based on V8) you cannot access out of bounds memory.

(You can have other problems like using too much memory, but you can do that in RUST too.)

RUST will let you turn off the memory checking - JS will not.

Obviously, writing in an interpretive GC language like JS is going to be slow. But for a program like sudo, which is ideally executed by a human, and processes very little data, it would be fast enough.

Note that JS can also call multiple system subprocesses and wait on them asynchronously.

Your reply is a sign you are not willing to even try to think out of the box. That's a cardinal sin. That doesn't mean your gut feeling is wrong, but if you can't explain it, it might as well be.

[fg_swe]

FAIL 2

I responded to "Even writing in assembly "allowed" programmers to write perfectly safe code". Now you start writing about JS.

Also, you implicitly call WASM-Programs "memory safe", which again demonstrates you lack of understanding of Memory Safety.

A C++ program compiled to WASM will have almost exactly the same/equivalent security bugs as the same program compiled to x86 or ARM machine code. If you lock down these programs using LSM, you have practically the same security properties as WASM provides. Sans the JS VM overhead.

Read here: https://www.williamjbowman.com/blog/2023/05/18/in-what-sense-is-webassembly-memory-safe/

There are very good reasons for the type systems of Sappeur and Rust, both in terms of security and in terms of efficiency. Low-level constructs such as VMs or CPUs are hard-pressed to replicate these capabilities and will consume many transistors or runtime to do so.

[fg_swe]

WASM, Sappeur, Rust

As this is an important subject, I have written a page about it:

http://sappeur.ddnss.de/SappeurComparedToWASM.html

[that one in the corner]

Re: NP complete

> "Programming languages which use garbage collection don't allow developers to write code in a way that's memory unsafe"

GC is to help you because you can not figure out when to release memory and keep running out of heap.

GC does *not* innately protect you against running off the end of a block you have hold of, or incorrectly sharing it with someone else. Or even creating cyclic references that can't be GC'ed and lock your program in an infinite loop, counting the elements in the supposed linear list. Or just putting your variables too close to global scope so you still run out of heap because nothing gets released and you are using 126GB of core.

A language with GC may choose to implement some mechanisms on top of GC that help with those problems, but that is not a given.

[fg_swe]

Re: NP complete

GC can collect cyclic hairballs of garbage objects. ARC cannot

[that one in the corner]

Re: NP complete

Bad phrasing on my part: the cyclic references described won't be GC'ed because there is still at least one active reference to that structure (the one being used to scan what was intended to be a list).

The actual problem being highlit is that the program is in an infinite loop, counting the entries, because creating - incorrectly - the cycle wasn't prevented by GC (as was implied by the post I replied to - i.e. the claim that GC solves all memory errors).

[Michael Wojcik]

Re: NP complete

the cyclic references described won't be GC'ed

Modern (like, since 1970) garbage collectors nearly always use algorithms that handle graph cycles just fine, thanks. Mark/sweep and color GC find the transitive closure of reachable objects and collect the rest. Sometimes those are augmented with various optimizations, such as generational collection or heuristics for identifying theoretically-reachable but never-reused objects. (The latter is in general uncomputable but can often be decided in practice for a non-negligible set of objects.)

Similarly, many modern GCs support weak or abstracted references which don't prohibit collection of the referred-to object, which a program can use during the object's lifetime without interfering with collection.

GC isn't suitable for all use cases, but trivial problems like orphaned object cycles were solved long ago.

[that one in the corner]

Re: NP complete

> the cyclic references described won't be GC'ed

Great strawman skills, deliberately only quoting half the sentence. Try responding to this quote:

>> the cyclic references described won't be GC'ed because there is still at least one active reference to that structure.

Yes, clever boy, GC will collect cyclic structures. That has been the case since the 1960s.

BUT so long as you have an ACTIVE reference, the GC "mark" phase will, correctly, NOT set that structure up to be reaped by the "collect" phase.

In fact, you even describe various *forms* of active reference (weak, strong)!

[Anonymous Coward]

Re: NP complete

GC does *not* innately protect you against running off the end of a block you have hold of, or incorrectly sharing it with someone else.

At least in the GC languages JS and Python, memory allocation is integrated with GC, so can not run off the end of a block or share it at all. You can share files, and read from pipes, and in JS you can perform those operations, in parallel, and join asynchronously. But you cannot share variables. (Unusual extensions notwithstanding).

Stupid memory usage design that runs out of memory is not equivalent to the problem of out-of-bounds memory access.

Notably you can run out of memory while writing in RUST as well. Of course because in RUST it takes 10~100 times more programming time to set up memory usage, it's going to make you think at lot harder about how its being used, and therefore keep memory usage as parsimonious and flat as possible - and that will make dumb memory usage design less likely, at a programming time cost.

So if you can, with experience, design non-stupid memory usage in a GC language, the work will be finished sooner. (Yes - the program will be slower - that doesn't matter if it is fast enough.)

[Anonymous Coward]

Re: NP complete

This was wrong and displayed ignorance:

There must be some good (or maybe even bad) reasons Linus Torvalds has shut down the idea of incorporating a garbage collecting language for kernel use for non-time critical operations - e.g., sudo. The discussion seems incomplete without hearing those reasons.

Actually - the kernel manage the authentication and credentials. sudo is simply giving a command (using setuid techniques) the permissions for root (i.e. user id 0).

That was obvious if I had thought about it. The mistake doesn't affect my main point, however.

[John Brown (no body)]

omits less commonly used features

And? The blog itself is no more enlightening.

I'd have thought something as critical as sudo being replaced would merit a lot more than just "omits less commonly used features" as a partial explanation of why it's better.

If anyone else is also wondering, one of the links in the blog leads to https://crates.io/crates/sudo-rs, hidden behind the words "first stable release" and is a link to the "read me". I'm disappointed El Reg didn't explain further or at least provide an explanatory link directly to the "read me".

Normally, I'm happy to go off and do my own research on something that interests me, but this one feels like fundamental information that ought to have been in the article and linked blog.

[pip25]

Re: omits less commonly used features

I was enthusiastic until I got to that sentence. A full rewrite would have been great. But now we have two, subtly incompatible sudos - and I guarantee that those missing "less commonly used features" will ruin quite a few people's day.

[Anonymous Coward]

Re: omits less commonly used features

> I guarantee that those missing "less commonly used features" will ruin quite a few people's day.

The Rust approach - you really, really should use our tools, even if they not quite all there compared to what you are used to.

[Cardinal Fang]

Catch is

1 of 3 bugs were memory management.

So Rust doesn't necessarily get rid of the other 2/3, and may even introduce some new bugs.

I'd be prepared to be that had memory check tools been available when sudo was written it would have been a lot less problematic, probably not memory safe but a lot less grief than it's been.

I'm not saying Rust is a bad language, and I'd call sudo ideal for Rust. The performance hit for something like sudo is well worth the cost, but assuming changing to a memory safe language is going to solve ALL your woes is being very naive. It's possible to do stupid in any language and in particular unexpected privilege escalation logic bugs is just as likely in Rust as in C.

[fg_swe]

Indeed

We should not use ABS brakes because they do little against drunk drivers speeding into a curve !

[Anonymous Coward]

Re: Indeed

Reading comprehension fail?

[Michael Wojcik]

Re: Catch is

assuming changing to a memory safe language is going to solve ALL your woes is being very naive

Who was making this assumption?

[Anonymous Coward]

Re: Catch is

I'd call sudo ideal for Rust. The performance hit for something like sudo is well worth the cost

I believe there should be no runtime performance hit for Rust. The hit comes in programming time. Compile time difference between C and Rust is also negligible.

[Anonymous Coward]

Memory safe code ..

> Memory safety bugs include issues like out-of-bounds reads and writes, and use-after-free().

How about designing a MMU that is not susceptible to such exploits?

"Memory management issues have been exploited for decades and are still entirely too common today"

DOH!

[fg_swe]

Explain

...all the details of such a microarchitecture that provides the same assurances as Rust or Sappeur.

Especially: have a concept of avoiding thread races.

If you need ideas, start with ICL VME Algol mainframe.

[fg_swe]

Re: Explain

More precisely the ICL 2900 CPU.

[Paul Smith]

Re: Explain

Why are you so keen on pushing the merits of a fifty year old computer from a company that ceased to exist over twenty years ago? This obsessive equine flagellation flagrantly promoting obsolete obscurities lacks relevance to the topics at hand.

[fg_swe]

History Lessons

Educated people learn from history while ignorants suffer old problems over and over.

Exactly this happens with those who blindly follow the Unix and C branch of computing.

ICL and Unisys had almost all we have in the JVM, but also inside the kernel. That's STILL more advanced+secure than Linux or Windows are TODAY.

Cola is not better than natural fruit juice, because Cola is younger or more hyped.

[fg_swe]

Re: History Lessons

Why do folks refer to Greek States and Concepts ? Because they had what we now have, 3000 years ago. Because they invented important practices and institutions.

ICL and Burroughs invented important techniques and should be recognized forever for this.

[Anonymous Coward]

Re: History Lessons

Conversely, natural fruit juice with 300 calories of fructose in a drink can cause the exact same sharp rises in blood sugar level that cola with 300 calories of sucrose does.

So if in response to a diabetes and obesity epidemic, you tax cola and tell people to drink natural fruit juice instead, you are killing them with lies.

You should instead say "eat whole fruit in moderation".

[Anonymous Coward]

Re: Memory safe code ..

Execution Speed/cost ratio?

[Adam Inistrator]

It is a good idea to have some safe version of c++ for simple but dangerous programming where it is just your code and os calls, but as soon as you start using libraries, all bets are off.