The Death of the Von Neumann Architecture | Hacker News Reader

The Death of the Von Neumann Architecture

codersnotes.com

105 pointskayamon75 comments

The "Von Neumann" and "Harvard" architectures mean something very specific in CS. The author is applying them to a higher level where they don't belong, which I find a little silly.

The reasons for Apple, Microsoft, and other vendors for restricting execution of native code are various, but mostly related to security and maintaining control of the ecosystem.

It is fine to complain about that desire for control. But it is not necessary to view this as a computer architecture issue at another level.

I think you have very much misread it.

I'm not complaining about desire for control at all. I'm complaining about the inability for a program to treat it's code and data as the same medium.

That is very much the key tenet of a Von Neumann architecture.

Although this is freedom-limiting, I strongly doubt that this thinking on iWatches will "infect" desktops in the future. The iWatch is designed to be an appliance, much like that microwave, rather than a computing platform for on-board idea creation.

Also, digital watches of all sorts have pretty much always been Harvard architecture for the past N years. From a use case perspective, the iWatch should be treated as a glorified digital watch, not a minified iPhone. Seen from this angle, I disagree that the iWatch is a "step backward". But I do agree with you that in general, Apple is annoying for deliberately limiting freedom.

Not to complain about terminology, but appliances used to be precisely the sort of stuff you could repair. I've fixed my microwave, I did not carry it to a genius bar. This is the reason why I fear this pernicious business model will spread: it promises lock-in for everybody, from John Deere to coffee machines makers.

As far as the iwatch being just a watch, the same thing could have said of the iphone. It was a phone, only cooler. Almost a decade later, ios devices are the platforms where many users do a significant fraction of their computing. And while ios devices may not require on bitcode submission, they limit the users freedom in a way that is fundamental. Image a world were every x86 computer sold post 1995 (outside of the server space) could only run Windows.

Besides, even if you own a "creation machine", you'll often be catering to the market of restricted devices (case and point: gecko on ios).

EDIT: I'll grant you may be right in the specific sector of non-computing electronics (watches, calculators, etc).

I dunno. I could see the likes of ChromeOS go down that path.

Never mind that iOS is getting more "desktop-ish" by the release.

That's a consequence of the Von Neumann architecture, not a tenant of it. All a Von Neumann machine is is one where both code and data exist in the same address space and are stored in the same memory pool (plus some other details). Apple's devices still do that, all the restrictions take place in the OS - well above the computer architecture level.

You might as well argue that Linux isn't really a Von Neumann architecture because you can only execute files that have the executable bit set.

You may have meant s/tenant/tenet. I'm only pointing it out because the typo is an extant word that may be interpreted to mean something proximate (but not identical) to what I think you actually meant.

Having read "The Computer and the Brain" by von Neumann. I would argue some key aspects of the von Neuman architecture are a computer's ability to store a program in memory, and have it fetched to run on the CPU. Another important aspect is a program counter(PC), and IO devices attached to the CPU via a bus.

The concepts that I would categorize as the von Neumann architecture are incredibly basic. Equating his plan for computer design with a difference between storing program/data vs. just program misses the mark. Von Neumann wasn't at all concerned with this difference.

Take this quote from "The Computer and the Brain": "Large digital machines are made up of 'active' organs and of organs serving memory functions-I will include among the latter the 'input' and 'output' organs.."

You can see how basic his thinking is by today's standards, and why Dijkstra later criticized him, and other American computer scientists for anthropomorphizing machines. He talks about 'an organ serving a memory function', he doesn't even talk about main memory because that word isn't in use yet.

You're interpreting von Neumann from a modern context. You don't understand just how basic and fundamental his ideas were.

Came here to say the same thing. Although the analogy kind of works (Von Neumann : open :: Harvard : closed), it seems really stretched. Let's not muddle CS terms with politics.

You don't like closed systems? Fine, but calling those systems "Harvard" architecture(s) is kind of misleading.

There is nothing stopping someone from implementing a Harvard architecture CPU which has the ability to move data to/from program memory. I've never heard of something like that though. So that would be "open".

In Microchip PIC land, that would be especially inconvenient, because of the different data vs. instruction size.

I think the author is confused. Protecting a code segment to be 'read only' does not change a machine from "Von Neumann" to "Modified Harvard" architecture. That distinction is reserved for computers that separate the 'store' (aka volatile memory) into two disjoint regions. And pure Harvard architecture machines (like the early PIC series from Microchip) suffer from an in ability to vary the partition between data and code, which is the real problem[1].

Now there is a pretty sound reason for making your code segment read only, and the author touches on it, which is that if you are running third party code, because it limits the attack surface for security exploits somewhat.

But then he goes off the rails with this claim, "What really struck me was that there was no flexibility here; no way to for a program to make changes to itself or build new subprograms, even if Microsoft approved it."

The next topic on the required reading list should be "Turing complete" :-) It is entirely possible to write a piece of code which is both a core interpreter, and the byte codes on which that interpreter is operating. And including in the byte codes a means to read, modify, and re-execute any previous byte codes. The sum of actions of course will be constrained by what can be expressed in a byte code but given that, you are free to do what ever you want.

And of course any interpreter which was interspersing its data and executable byte codes in the same chunk of memory, well that would be a Von Neumann architecture :-)

[1] Harvard machines ultimately fell out of favor because you could end up with left over code store and not enough data store for an application.

I think it's all about performance.

> Now there is a pretty sound reason for making your code segment read only

Sure, but I've had enough situations where ability to generate code made inner loop 2-3x faster, by removing branches and constant folding. Difficult? Yes! Error prone? Yes! Fast? Hell yes!

> It is entirely possible to write a piece of code which is both a core interpreter

Yes, but it's going to be 10-100x slower.

So every program needs to be wrapped in an additional VM?

[Hi kayamon, I am presuming you're Richard, if I'm mistaken in that please let me know.]

Collected together for one response ...

   > On a machine where programs are supplied as bytecode,
   > there are indeed two disjoint regions.
   > The bytecode sits in it's own region. You can't 
   > touch it from the data region.

Doesn't that depend on how you define the byte code? If I define byte codes as follows,

   0x01 0xnn 0xmm load a byte from offset 0xnnmm in memory.
   0x02 0xqq      load qq into accumulator immediate
   0x03 0xnn 0xmm store accumulator into 0xnnmm in memory
   0x04 0xnn 0xmm set program counter to 0xnnmm
   0x05           increment accumulator

Then I put

   02 00 05 03 00 01 04 00 00

Into memory, and "run" my byte code, This program self modifies the load immediate value continuously.

When Java defined its byte code it went out of its way to avoid 'pointer arithmetic' to make the language safer but even in Java's heap model the memory to store data and executable content is the same memory, it is an artifact of the Java byte code definition that it doesn't allow for self modifying Java code, it has nothing to say about byte code in general. And the point where things get confusing for me is that architecture is reasoning about structure in general, where as implementation is reasoning about structure in specifics. So there is nothing architecturally significant about byte codes with respect to computer architecture, other than you can simulate a variety of architectural choices by how you define your byte codes.

   > So every program needs to be wrapped in an 
   > additional VM?

No. The point was that your blog post conflated computer architecture with an implementation choice made by a particular vendor. Many vendors have chosen to create implementations which make implementing self modifying code difficult. They have their reasons, and you elucidated on two of them, rights management and security.

That they have done so, gives them some benefit, and it comes at some cost to you, the developer.

When looked at from a cost / benefit point of view, I would be interested to read about how those design choices constrain your ability to deliver a compelling game experience, or a needed capability. To often these things are only discussed in terms of what they do for party A or party B and rarely do we get some thinking on what we cannot have because of the constraints imposed by their implementation choice.

You're absolutely right that bytecodes in general are just like any other instruction set, so can be modified etc.

I guess I'm using the term 'bytecode' to refer to systems such as Java, where they don't let you mess around with it much. It's almost always the case for any implementation of a bytecode system that they don't treat it as writeable data.

> That distinction is reserved for computers that separate the 'store' (aka volatile memory) into two disjoint regions

On a machine where programs are supplied as bytecode, there are indeed two disjoint regions.

The bytecode sits in it's own region. You can't touch it from the data region.

I believe you are misunderstanding the use of bytecode in the Apple Watch: What is deployed to the device is still native code, the bytecode is merely what's submitted to the app store.

But if the program has no knowledge, visibility or control of the native code, it effectively does not exist.

Von Neumann Architecture has been dead and buried for 20 years. We only imagine our x86 is Von Neumann because there is coherence between the instruction and data caches.

Every modern machine is a Modified Harvard Architecture.

http://en.wikipedia.org/wiki/Modified_Harvard_architecture#M...

> Every modern machine is a Modified Harvard Architecture.

Well, this is just not true if you consider all modern computing systems rather than just desktop computing.

Every modern microcontroller is either Harvard, or pure Von Neumann. And there are billions upon billions of these shipped every year: ARM microcontrollers ship at a rate of 35Hz! Generally the lower power parts tend to be Von Neumann.

The AVR family of microcontrollers are Harvard machines. http://www.atmel.com/technologies/cpu_core/avr.aspx

As are many of the PIC series of microcontrollers.

The Harvard/Von Neumann distinction is from an era before the modern break between macro and microarchitecures. It would probably be most accurate to say that modern ISAs present a Von Neumann macroarchitecture but actually implement it in a Modified Harvard way.

Would you have other sources even for the term "Modified Harvard Architecture" ? I struggle to find others than this Wikipedia page.

If you like this article, you'll also like:

"The Coming Civil War over General Purpose Computing": http://boingboing.net/2012/08/23/civilwar.html

"The Right to Read": https://www.gnu.org/philosophy/right-to-read.en.html

Not to detract from the author, however:

Or perhaps you’re running on an OS that doesn’t have any support for hot-patching a running executable with new code. And you think “I know how to write a programming language runtime that can do that.” Perhaps you’d seen how Erlang can do it, and wanted to try it yourself.

Dynamic code upgrade is really rare in general. The most that's usually done in mainstream practice is to pass socket fds to a newly exec()ed child instance, or some other form of superserver/pre-opening, a la inetd, UCSPI or whatnot.

What if you were on a system that didn’t support DLLs or shared libraries, and you thought it’d be kinda useful to invent something like that?

Depends on what your purpose for shared libraries are. If you just want a plugin system, then the traditional way w/o shared libs is to use some form of RPC so as to coordinate forked OS processes.

Finally, the majority of our programming languages are firmly in a von Neumann model, so it isn't quite dead yet. Not sure if read-only code segments are enough to deliver its eulogy, either.

> Apple’s own Safari compile scripts to assembly because they’ve helpfully added a secret backdoor just for Safari, but not for any other programs .. On one benchmark, LuaJIT’s ARM JIT is 48X faster than its own interpreter. Android can run the JIT version, but iOS can only run the interpreter version.

How many years will it take for an antitrust regulator to level this playing field?

Who are you going to sue? The LuaJIT project, for exerting its monopoly on Lua?

The vendor implementing backdoors for commercial reasons, limiting competition for performantly rendering 100% of web sites?

If you're simply concerned with the backdoor, I guess I'm completely confused why you also quoted the bit about LuaJIT iOS vs Android performance.

Are you trying to say that not being able to run the faster JIT version of LuaJIT on iOS is anticompetitive?

Javascript and Lua are two examples of languages where users have benefited from JIT compilation to assembly, as proven by performance benchmarks on multiple platforms. Both languages are artificially constrained by iOS restrictions. Safari's Javascript is one example of Apple implementing a JIT backdoor/exemption that favors Apple and excludes competitors like Mozilla Firefox.

If a regulator took action, Apple would have a choice of giving up JIT on Safari or permitting JIT for all apps on the platform. Practically speaking, they could not impose a JS performance penalty on every user of mobile Safari. It is more likely that Apple would permit JIT for all iOS apps. This would then benefit LuaJIT and all other dynamic languages on iOS.

A-ha, I didn't understand what the backdoor was.

I'm still not sure you could bring an antitrust case against them- to apply antitrust law they have to be abusing monopoly power, and they don't have a monopoly on mobile computing- but it makes more sense. Thanks.

Apple have a monopoly on app distribution within iOS and are favoring Apple-owned Safari to exclude all competitors.

Apple can either:

  • give up their iOS app distribution monopoly (allow other app stores)
  • give up their iOS browser monopoly (allow other performant browser apps)

That isn't how antitrust works. If Apple, for example, didn't allow anyone other than Apple to sell software for Macs- that isn't antitrust until Macs have a monopoly in the personal computing market.

You can monopolize your own ecosystem all you like, so long as your platform doesn't have monopoly power.

If iOS eats up all Android's marketshare and becomes the only platform worth a hoot, then you can start filing antitrust cases for this kind of thing.

The only reason Microsoft's IE bundling with Windows was antitrust was because Windows owned just about the entire personal computing market. Otherwise it would have been fine.

Some say Intel tolerates the existence of AMD, because if AMD completely disappears Intel suddenly becomes a true monopoly power and vulnerable to all kinds of antitrust suits.

It's hilarious to me that the same dirty tricks that led people to crucify Microsoft in the 1990s (OMG! Office can use an internal API!) are important security measures and perfectly legitimate restrictions in the eyes of Apple apologists.

And you are not the only one. Well, it is actually just depressing.

Someone just needs to make a better computer that people can switch to from Apple. No need to bring violence into the equation.

We know the formula now, which Microsoft ignores since their market is companies. The formula for selling computers to people seems to be "be in control of both hardware and software to provide the best native experience". It's not a secret, anyone that wants to can start a company and compete with Apple. All regulators can do is make Apple's job harder for themselves which will result in bad products and cost taxpayers money, a lose-lose situation.

The formula also includes factory financing which slows competitor access to manufacturing capacity. Some products benefit from network effects (manufacturing, developer adoption) and become difficult to displace by any competitor, however well funded. Careful intervention can help to restore balance.

Unlike the oil companies of yesteryear, or even a browser that is supposedly "baked into" an operating system, the remedy here is not logistically complex: the backdoor is already known to exist -- it can be extended to some competitive products.

> The formula also includes factory financing which slows competitor access to manufacturing capacity.

I'm talking about the formula that seduced the customer. "Factory financing" did not seduce the customer - one company in charge of the whole computer (as opposed to one company making the hardware and another making the software) is what seduced the consumer. The fact that company makes computers for end users, not company employees, is what seduced the consumer.

> Careful intervention can help to restore balance.

Like non-violent spanking, careful intervention is an oxymoron. Unless you can show an example where no one was harmed by government anti-trust laws being applied.

It seems disingenuous to write an article extolling the benefits of JIT and self-modifying code without mentioning the security concerns of allowing anyone to change executable code.

You say "disingenuous", I say "focused". :-)

Whitelists can be maintained by the device owner/administrator, instead of the device vendor.

You don't need to be able to change code to execute arbitrary code --- see return-oriented programming. Besides, NX gives you almost all the same benefits.

Restrictions on code execution strike me more as business controls (and yes, assaults on freedom) than real security measures.

Look at my other response in this thread, ROP isn't trivial these days due to ASLR implementations. Almost always one needs information leak bugs.

The presence of a JIT makes things trivially abusable for the attacker and is a big security risk.

More disingenuous than somehow confusing policies of vendors with fundamental CPU architectural paradigms?

The technical points mixed with the politics is a little boring. I'm really over people trying to make a moral issue out of iOS. You totally have the freedom to ignore platforms that don't work the way you want.

I also agree you have the freedom to complain about things over and over endlessly but yawn

iOS has 42% marketshare. You can't ignore it. When a company is moving in the direction of removing freedoms from 42% of the market, that's a political problem that should be addressed and not ignored.

Sure he can. And besides, Apple won't change course because us devs worrying and they never have in the past. Neither did Microsoft, at least not out of free will.

The only power we have is buying power. Ranting and politically complaining as the article does won't change anything.

> Ranting and politically complaining as the article does won't change anything.

Yes it does, it educates readers, it can convince others not to buy iOS devices.

Other articles have certainly convinced me of that, for which I am very thankful to the authors.

These articles are not for Apple, they are for the people. People like us in Internet forums, who then discuss them, learn something (or not), and then make a decision (or not).

Back when Microsoft had 90% of the browser market share they could have pulled an Apple and locked everybody else out of the web. The only reason they didn't do that was because the antitrust regulators didn't let them. But if it had been left up to the "buying power" of consumers we would have lost one of the greatest inventions of our time to an awful greedy corporation. The iPhone probably wouldn't even exist or they would have to license IE from Microsoft.

"The only power we have is buying power."

That's what this article is trying to fix.

42% in the US, not in the real world

I think that this percentage does not matter as Apple controls 100% of the entry into market of iOS applications.

In case of Microsoft IE, every other company was able to provide software for Windows without MS vetoing it. This situation is different - Apple is 100% controlling the entry into market for other entities.

Excellent point. It's hard to track the unfair advantages which Apple has reserved for itself, especially when their control of one axis is 100% (fish in water).

In the 90s when Microsoft was in the same position I agreed with your point regarding Java and a host of other t technology that I thought was unfairly pushed out of the market... The thing is though by the time that remediation under regulation got underway the sea change had already started. Technology is one of the only sectors where that k kind of thing happens.

Another commenter also had a good point about global markets... Apple has that market share in the us... It's actually very small globally.

You make valid points though... Just saying that this stuff moves very fast.

I second to this.

I think that we, software developers have a moral obligation to make ethically right decisions. Supporting or ignoring app store business model(1) is in my opinion not one of them.

(1) this is, having one entity to control entry into market for everyone else - this creates monopolies - no, it does not matter that Apple has only 42% of the smart phone market share - it has 100% of iOS market share and is using its monopoly power to control this market.

We should force everyone to have their security lowered to Android level is hardly the ethical summit.

Users should be in control of their phones. There's a big gap between allowing malware all over the place and limiting things to a single app store that takes a 30% cut and randomly delays updates or pulls apps altogether.

You are making it appear as Apple control over app store is about security when it is not. I would believe it when they blocked and removed only malicious applications but instead they are also removing applications that they think would compete with their own products or with their business strategy.

There's also a counter-point: Harvard architectures are more secure. If the application has the ability to execute data as native code, attackers will find a way to exploit that.

Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants. Doesn't matter if there are no pages that are both writable and executable. Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time.

http://en.wikipedia.org/wiki/Return-oriented_programming

It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated).

With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written.

Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.

latiera, you seem to be banned for some reason. Both of your comments are dead. I'll quote your post in full.

> It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated).

> With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written.

> Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.

Of course ASLR makes ROP harder. It makes all exploits harder. I still don't agree with your last paragraph. As someone else mentioned, good JIT implementations never leave code both writable and executable. It's simply not the case that "page permissions are irrelevant". Page permissions are central because they defeat the specific attacks you have in mind. A JIT is no more vulnerable to them than the dynamic loader is.

I still don't buy that banning PROT_EXEC buys you any protection from attackers exploiting applications.

On the other hand, banning PROT_EXEC provides plenty of protection against uppity application developers trying to "abuse" the platform you "own" by attempting to program in unapproved ways.

Exactly.

To add, nothing prevents from allocating pages from random addresses to get protection similar to ASLR.

It can actually be harder to attack dynamically generated code, because instruction offsets and instructions used will vary from application invocation to another. You could even do intentional variations to ensure no relative instruction offsets are deterministic. So dynamically generated code can have not only have random address (ASLR) but also random relative offsets. Obviously statically compiled code must have those offsets static, known by the attacker.

ASLR just means you don't necessarily know where. But once the attacker knows where or has some clever trick so it doesn't matter, it's game over. Unfortunately the creativity of attackers getting around ASLR seems to be endless.

> Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants.

That's like saying there's no point in locking your doors because thieves can go in through the window. Instead, you're better off applying separate defenses against separate attacks: read-only code against code injection and other defenses (like CFI or randomization) against ROP.

> Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time.

Sure, but it's amazing how few actual JITs do that. V8, for example, actually maps its entire code cache as RWX.

> Languages like Java, JavaScript, or the .NET framework could never have prospered on platforms that didn’t allow them to create new native code as they ran.

We can take this a step further and say that if IBM locked down its PC back in the 80s, we wouldn't have Linux!

>Apple and Microsoft are showing every indication that within the near future this direction may well apply to desktops too. The restrictive ‘store’ APIs pushed by these platform holders seem to relish in preventing the execution of unapproved code.

Not really. Windows 10 apparently allows universal Windows apps to call VirtualAlloc() and VirtualProtect().

http://blogs.msdn.com/b/chuckw/archive/2012/09/17/dual-use-c...

> Windows 10 apparently allows universal Windows apps to call VirtualAlloc() and VirtualProtect().

Yes, but they're useless for this purpose. VirtualAlloc is mapped to VirtualAllocFromApp. Which means you can't allocate executable pages.

You can't make a page executable. Nor can you make executable pages writable.

So you can't run dynamically generated code at all in a Windows 10 universal app.

It's hard to tell if that's the case or not - the documentation seems to contradict itself on that point.

Come to Android, where mprotect still works.

> "A step backwards to the Harvard architecture benefits no-one."

Actually it benefits Apple, which is why they did it. Or is the author arguing it doesn't benefit Apple? However, I didn't see anything substantiating that in the article.

Sounds like "Java Phones." It was being done way before Apple got involved.

I don't think using proprietary platforms such as Xbox 360 or iOS as examples constitutes a trend in the field of Computer Science. It's more likely that Apple will reject your iOS app for some reason than it is that you won't be able to "innovate." If you want to innovate on iOS and create something truly spectacular, you should be seeking employment or simply be satisfied hacking the provided device yourself.

I would consider this article's content far more substantial if there was an example of this architecture being used in, say, Linux 4.

Do you really believe in this what you wrote here??? Are people completely lost their dignity?

It used to be that the owner of the operating system did not have any say about what other developers can write to that platform.

> It used to be that the owner of the operating system did not have any say about what other developers can write to that platform

It used to be that "online lobbyist" was not a job description, http://www.washingtonpost.com/blogs/monkey-cage/wp/2014/06/0...

Reply on news.ycombinator.com