Unclear what the article is really talking about. However, regardless of programming language, I do think that microarchitectures could do more for security. When going for memory safety, why stop at the highest level?

Frankly, if it were about memory safety, though, I think we could count C out. A microarchitecture with inherent protection against memory bugs would likely not be able to provide it's advantages to vanilla C or existing C software.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri... sounds promising.

Unfortunately, given the industry reliance upon standard C, I doubt capability machines will ever catch on.

CHERI a capability machine designed for C programs that runs FreeBSD.

My point is more that it requires modifications to existing C code to use the full capabilities (no pun intended) of a capability machine.

I wonder if this could be done with an alternate stdlib. Editing the usual e.g. heap management functions et al. so it does stuff behind the scenes.

Why not get safety AND easy concurrency by going to Software Transactional Memory in hardware? I don't know the specifics of the overhead off the top of my head but I imagine we're getting close to the point where it's a reasonable cost to bear for the benefits it would bring...

Do you know what JVM , Node, python runtimes are written in? Its not like there aren't bugs in other software. When you have millions of lines of code there is always going to be something that some one forgot to think about.

Unless you have a very trivial program I think its hard to make anything "unhackable."

>JVM

Well, here's a Java Virtual Machine written in Java: https://github.com/beehive-lab/Maxine-VM

Not to counter your point, but to keep the discussion going :)_

> Do you know what JVM , Node, python runtimes are written in?

this doesn't matter to its following theses:

> Its not like there aren't bugs in other software.

There were/are architectures (Burroughs large systems, iAPX432, to some extent AS/400) with fine-grained memory protection which essentially solved all the memory safety issues. Apart from the fact that some such machines were terribly inefficient (eg. iAPX) the major reason why you don't see them that much today is that there was no sane way to run existing C code (or any other code that expects flat memory space for that matter) on them while preserving the safety features.

So the bottom line is that such hardware architectures necessitate using more high-level languages than C.

I worked on Burroughs large systems - they had a stack architecture and memory locations were tagged by data type to ensure safe access. ALGOL scope rules were effectively enforced in hardware. The issue even then was that these rules did not work once you moved to COBOL, or C or other languages which had different scope rules / data types from ALGOL and so hacks had to be used which effectively gave up a lot of the safety features of the hardware.

Security cannot be achieved by merely avoiding programming mistakes.

The question is not if it can be made perfect, but if it can be improved.

If you fix it in hardware you wouldn't have to rewrite everything in a different language. That sounds like a pretty good solution to me.

I feel like that $3.6 Million in funding go a lot further if spent on projects like the Rust Language.

Rust's safety was partly inspired from such spending on Cyclone, a safe version of C. The NSF and other organizations fund tons of work on clean-slate languages, type systems, formal methods, etc. The academic incentives usually lead to quickly thrown together prototypes that arent production ready. Even the good ones rarely get used by programmers in general. Ocaml was one of the exceptions. What gets adoption is normally a language/platform with a knock-off of their efforts pushed by a big company or used in a "killer app." Bandwagons in other words.

The consistently-low adoption of clean-slate tech along with lock-in effecta means the opposite is true: massive investment should go into making most common tech more correct, secure, and recoverable as simple as possible for users. If clean-slate, it should stay close as possible to what people already know with clean integrations. We can also continue to invest in ground-breaking stuff for niches that use them (eg SPARK Ada for aerospace) and/or new bandwagons that might build on them (eg Rust ecosystem).

I had forgotten Cyclone's name, thanks for the reminder. I've always felt kinda sad some of the small features like int@ didn't make their way back into C. I'm glad at least C++ has non-null pointers via references (but with stricter semantics and potentially undesirable syntactic sugar) and fat pointers via span<T>, but it's useless when I have to write in C for legacy reasons.

Trevor Jim revived it a bit with virtualization for those wanting to play with it:

http://trevorjim.com/unfrozen-cyclone/

Oh, that looks interesting, thanks for the link!

So instead of spending money on a completely revolutionary approach that would add an additional layer of security in addition to whatever an up-and-coming language that's already doing a tremendous job at raising awareness about the relationship of programming languages and security as it invents a new paradigm (the borrow checker), we should just give it to focus on the latter?

Rust isn't a panacea. Research funding should go towards exploring a wide array of subjects. Doing anything else ends up with a monoculture.

Agreed. Although I do think that memory safe systems languages are seriously low hanging fruit.