Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Stack, bounds, and code vs data checks like Burrough's can be encoded with almost no gates in a processor. They can run in parallel to main CPU's activity with CPU results only written if checks succeed. One aspect of SAFE architecture at crash-safe.org did that along with some others. So, no, it's pretty easy and not done since modern processors are optimized to run unsafe, C code. ;)

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

View on HN

So, in other words, a tagged architecture, except the possible values of the tags are "usable" and "not usable"? Sounds horrible - it's the hardware equivalent of checking at runtime whether a variable is in scope in, say, Python or JavaScript. I don't see any point to checking at runtime what can be known statically.

The tags are more commonly a few types like scaler, array, pointer w/ bounds, and so on. It checks basic stuff rather than full heap safety. Too tired to remember if there's one on that. The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation. The basics that go the furthest cost little to nothing in many designs.

Then, you can go from there in your language or compiler design.

> The point was that runtime checking of critical aspects of safety isn't necessarily some high-overhead operation.

The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous.

"The runtime check doesn't make the operation any less unsafe - it only makes the consequences of an error less disastrous."

I think we have a different definition of unsafe. If you think it's potential to cause problems, then I agree it doesn't make it less unsafe. Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system. That's what I'm claiming. Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.

> I think we have a different definition of unsafe.

“Potentially without useful meaning”, e.g., indexing an array without knowing whether the the index is within bounds.

> Alternatively, it does make it less unsafe if that means it reduces the ability to invisibly corrupt data, hack your system, or crash your system.

Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!”

> Even Rust or Ada might have a hard time meeting that definition once their pristine codes are converted into assembly.

As long as the assembly code has the same meaning as the safe program from which it was generated, it's safe.

"Your kid (your data) attends the same school as a bully (your program). One day, the bully threatens to punch your kid in the face (raises an exception). “But it's less wrong because he never punched your kid! He only threatened it!”"

You're going out on a limb here. I'm not even countering that example as it's rigged to prevent that. Instead, I'll point out these unsafe things don't happen in a vacuum: there's something in the language that sets the risk in motion and then there's something else that determines what happens. The compile-time safety stops it from being set in motion. The run-time safety makes things set in motion meaningless as they'll just be exceptions or alerts for admins.

Back to your analogy, it would be more like a prison learning environment where people learned in cells with bulletproof glass while one shouted he was "gonna cut someone" for not sharing answers. He can try every unsafe thing he wants but the glass makes it meaningless. The prisoner that's being targeted can literally just pretend all that unsafety doesn't even exist with no effect.

Ideally, we have prevention and detection. Reason for prevention is obvious. Reason for detection, even in a perfect language scheme, is because compiler or hardware errors (esp SEU's) will make something act badly eventually with runtime measures being last-ditch effort. If there going to be there, though, then might as well lean on them some more if there's no performance hit, eh? ;)

If my analogy is is flawed (which it almost certainly is), yours is even more so: the computing equivalent of your analogy is preventing runtime errors by simply not allowing software components to interact - yes, of course, without interaction there are no errors because there is no computation!

I was thinking about that as I submitted it but was multitasking. You called it so I gotta correct it. So, let's drop the analogy and go back to what I originally claimed: CPU's modified to protect pointers, arrays, stacks, and so on. The primitives forced to be used in acceptable ways. The programmer does the rest expressing the problem in the type-safe HLL.

Now, almost every hack on a system that I can think of requires forcing a pointer to go out-of-bounds or something like that. Further, the rest send in data that becomes code. One check, from Burroughs, is CPU looking for code tag bit before executing which only can be set by OS or isolated service on microkernel. So, that wouldn't work.

What remains, with little performance hit & no static checking, is a system where hackers (a) have to con the admin into installing malware, (b) break the minimal, trusted loader/installer w/out abusing above components, or (c) get a denial of service attack. Forget analogies: the reality is much more impressive given there's almost no high-severity CVE's left. You can also do great static checks and such as I always recommend. Yet, you either don't or rarely need them in practice if goal is integrity or confidentiality rather than availability.

"Check and incidentally... mate" (Sherlock Holmes, Game of Shadows)

> Yet, you either don't or rarely need them in practice if goal is integrity or confidentiality rather than availability.

My goal is correctness. A program that fails with a runtime exception is just as wrong as another that silently corrupts your data. Dijkstra put it very nicely:

“We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. (...) The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be "almost correct", afterwards a program with an error is just "wrong" (because in error).”

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/E...

Cute quote by Dijkstra that shows he hadn't quite figured out reality yet. So, correctness is your goal. That means you'll have to specify the behavior, safety/security policy, and prove the two equivalent. The implementation, both source and binary, will have to be shown equivalent along with proven free of language-level issues. Finally, you have to do that on triple, modular hardware [1] that's rad-hard w/ similar rigor in its lifecycle. Or use run-time checks [2] for each algorithm that can correct errors probably also on TMR or rad-hard board. Let's not forget the custom circuitry for RAM that works [3].

Darn, Dijkstra or not, you still need some kind of runtime checks and protection for correctness. :)

[1] http://www.rockwellcollins.com/~/media/Files/Unsecure/Produc...

[2] https://galois.com/project/copilot/

[3] https://research.google.com/pubs/pub35162.html

Interesting read. Why wasn't the Burroughs more successful?

I guess money, if you look at the history of computers the majority of interesting stuff failed because it didn't managed to pay for the investments that were done.

C and UNIX got widely adopted, because AT&T wasn't allowed to sell it, so they gave the source code for free to universities. Which then used the code to replace the expensive OSes that they were running on their mainframes.

When AT&T was allowed to charge for it afterwards, they tried to make people pay for it, but failed to do so.

Also around this time UNIX vendors started selling the developer tools separately instead of having them for free. This motivated many to contribute to GNU, which was largely ignored up to that point.

Sending you this link as you might have missed what actually happened on Burroughs end. I thought they petered out and got bought by Unisys. I didn't realize they were Unisys plus were selling billions in MCP systems.

https://news.ycombinator.com/item?id=11621318

So, it wasn't the money for once.

Thanks, I discovered that recently when reading about NEWP.

Have their programmers manual on my reading list.

But got the idea it is a very niche market, even smaller than IBM mainframes.

That's probably true. Most material on the mainframe market says IBM has around 90% of it. Their revenues tend to suggest that, too. Probably the common effect with the First Mover advantage. I'm sure IBM bribing government officials in exchange for contracts helped, too. Let's not forget that angle. The NSA business alone would've been enough to found several, computer companies. ;)

It is successful if you give it a different name: Unisys.

https://en.wikipedia.org/wiki/Unisys

"In September 1986 Unisys was formed through the merger of the mainframe corporations Sperry and Burroughs, with Burroughs buying Sperry for $4.8 billion. "

"The merger was the largest in the computer industry at the time and made Unisys the second largest computer company with annual revenue of $10.5 billion"

As to why IBM dominated, I have a hypothesis that's consistent with what happened to other companies. It's basically Gabriel's Worse is Better effect where certain characteristics improve marketing & uptake. The IBM mainframe, IIRC, were backward compatible or integrated with stuff IBM people already bought. They were optimized for Fortran etc that existing apps were written in where Burroughs was optimized for Algol, the language of the future. Further, in a trend that still exists, people focused on raw performance per dollar instead of reliability, maintenance, security, technical debt reduction, and so on that Burroughs architecture could provide. Similar effect with Intel i432, i960, and later Itanium w/ its excellent reliability/security improvements. Burroughs started taking out hardware security & recently got ported to Intel CPU's IIRC. Intel just stopped taking chances. Both in legacy mode since it's all people buy.

Sad story of how computer market works. The Burroughs systems are still around, though, with Unisys making plenty of money. MCP is on release 17 with Unisys also releasing a tool that lets you run MCP in a virtual machine on a PC. It's called MCPExpress I believe. Here's the page.

http://www.unisys.com/offerings/high-end-servers/clearpath-f...

Reply on news.ycombinator.com