Hacker News Reader

Comment by bvinc | Hacker News Reader

He talks like the way he writes code has been established as best practice for decades, and if he can just write enough blog posts and convince enough people, maybe we can solve this problem once and for all.

I think the only way to have high assurances is to program under a system that doesn't have these classes of errors. I don't care if it's a c static checker or a new language or what.

Unfortunately the long term solution to these problems in system programming seems to be rust. But it's going to take decades for it to be established and I'm going to look like a language hipster member of the rust evangelism strike force every time I bring it up.

But seriously, it's been decades and decades and we're still writing buffer overflows. What is the long term final nail in the coffin for buffer overflows?

View on HN

> But it's going to take decades for it to be established...

I wouldn't be so pessimistic. Software is becoming increasingly complex and many people are starting to see that it is starting to get a little ridiculous. All we need is a tipping point in the form of a well designed kernel that works well. It doesn't need any hype, no HN announcements, nor major corporate backing. It just has to work and work well. That's how Linux got started. It filled a vacuum. We still have a vacuum in the form of crusty OS designs patched over with layers of code miles deep. That vacuum is the need for a new clean system for the networked distributed resource internet age.

What we need are more passionate hackers who work on this for the pure enjoyment and self satisfaction instead of selfish ego fueling; meaning don't code with the end goal of getting something on the front page of HN/Reddit or super git committer. Just code for the sheer enjoyment and challenge of it. Besides when you post these ambitious projects you get all sorts of jealous reactionary posts that attempt to pick apart your ideas and stomp on them. That can discourage people from making true progress.

The long term solution is to burn down x86 and C and start over with sane hardware, which has bounds checking in hardware.

I'm curious; what does your memory hardware and cpu instruction set look like in this scenario? What's the interface between the cpu and memory? (rough idea, not asking for a whitepaper here :) )

Consider the scheme 79 chip: http://dspace.mit.edu/handle/1721.1/6334

> bounds checking in hardware.

What. That's a horrible idea. Not only would that require your hardware to understand abstractions several layers above what it actually operates on, it would also mean it'd have to check bounds of - for example - an array on every instruction accessing it. That is something compilers can do at more strategic places.

Please keep that complexity out of my CPUs, they're buggy enough already. At least with software we can fix issues later, which isn't a given with hardware.

Turns out the x86 already has some bounds checking support; see chapter 17 in volume 1 of Intel's developer manuals and the BOUND and BND* instructions.

In fact they were removed in 64 bit mode. Same for INTO

LoadAddressIfSmallerThan makes for a long opcode name, but it doesn't look much more complex than your usual load. The added complexity is negligible.

And, of course, the added complexity of doing that in two instructions is also negligible. The entire problem seems to be that arrays are on a more abstract level than C operates. It looks like entirely a language problem.

Having the CPU do the checking within an instruction saves you instruction issue events. ARM have an interesting solution to this, pointer authentication: https://news.ycombinator.com/item?id=14479438

> several layers above what it actually operates on

The instruction set is something of an abstraction bottleneck - C is tied to machines that look something like a PDP-11, while a lot of the stuff that the machine is doing is invisible at the instruction set layer.

Pointer authentication is not a form of bounds checking. It solely exists to prevent a malicious attacker using a bug to directly overwrite pointers (and in practice, it's mostly limited to return addresses right now). Code which does buggy pointer arithmetic will still create valid pointers to data outside the intended buffer.

> which has bounds checking in hardware.

x86 has bounds checking in hardware. it's called a page fault.

[edit: formatting]

Segmentation was expensive (loading an 80286 segment register was very slow and the segment table was impractically small) but could express "offsets between 0 and 42 are valid". Paging is much coarser and suffers from false negatives, because x[y] might accidentally walk off the end of x, skip a guard page, and land on a mapped page from another object.

Not quite true: There would not exist exploitable buffer overflows if that was the case.

I worked (a long time ago) on Burroughs mainframes which did bounds checking of arrays (and in fact even type checking), because the whole machine was build around ALGOL.

I am not sure whether the experience from these machines was negative. It may be that when you move beyond one-dimensional arrays, bounds checking becomes more complicated.

Perhaps performance suffers too. Languages which do bounds checking often have intelligent compilers which can skip the bounds check in a variety of conditions. So even if the hardware is faster, it may be doing unnecessary checks. See for example : https://www.ardanlabs.com/blog/2018/04/bounds-check-eliminat...

I also believe that bounds checking in hardware is not worth it. Memory accesses dominate the runtime such that a few extra instructions for bounds checking is negligible.

Rust isn't the long term solution either. I like Rust, but in terms of fully provably secure systems, it's a stopgap until the usability of fully verified approaches like ATS, F-star et Al reach a point where they can be economical.

Also what the other person said about burning down x86 and starting over.

Those are all things that could fix the problem. But let me ask this another way. Imagine that you travel into the future a decade or three and a computer scientist tells you "pretty much no one gets buffer overflows anymore because of X".

It seems unlikely to me that the answer is going to be ATS, or "we burned down x86".

Ok, sure, if you only focus on buffer overflows. Those are the low-hanging fruit of software security. If in future decades we can say "professional software is pretty much secure because of X", X is absolutely not Rust. And I don't think we'll still be using x86.

Reply on news.ycombinator.com