Ran into this a couple days ago - but it is a couple of years old.
A new CPU architecture that, by the looks of it, is trying to remedy some of the shortcomings in modern CPUs.
ootbcomp.comYouTubeHaving watched 3 videos I find this stuff fascinating.
I remember it was a kind of stream processor. Interesting indeed.
Yeah, I've been tracking it for sometime. Gandalf presentations are fun to watch, but architecture itself is very questionable.
There has been a number of similar architectures designed over the years, mostly by researches with no implementation in hardware. Counterflow Pipeline is a good example of one, but there are many others.
Mill will have a ton of problems scaling up to a level of modern processors. It will have huge problems with things like caches, virtual memory, memory protection, virtualization.
I'll wait until there's actual silicon that can be tested against real-world problems. So far the most impressive thing about the Mill is their PR machine.
I don't care if they ever build it. I like thinking about this stuff and I love hearing about other people's ideas.
(just had a nice idea myself but not sure if it can be done
)
We have ben stuck in the VonNeumann architecture for way too long and this has been very detrimental in some aspects.
Most importantly security is impossible on a VonNeumman machine because everything is on the same memory space. therefore the machine can't keep itself secure from itself.
Turing and VonNeumman knew the security implications of this, matter of fact they knew everything there is to know about information theory but none of that was important in their time.
My theory is that at a later date somebody decided that this situation should be perpetuated for consumer equipment.
I don't think a non-VonNeumann architecture would have been allowed to proliferate the consumer market. That decision was probably made at somebody's desk at the Pentagon some time in the 60's or 70's, probably after analyzing VonNeumann's report on the architecture.
He did not invent that architecture btw, he was merely reporting to the big brass about the work of Eckert and Mauchly who were building ENIAC. VonNeumann was the highest vetted computer and code expert at the time having been on the American side of the Enigma work. He was probably submitting daily reports about the work including security and vulnerability analysis about the machine and the people working on it.
Until recently it was kept secret but most of the Bombe code crunching work was actually done in America under VonNeumann's supervision. The data was relayed by undersea cables each day and there were far more Bombe machines in America than there were in Bletchley. Nobody was allowed to know.
Turing in comparison on the British side was not well indoctrinated and not at all trusted. As soon as the war ended they put him to gather dust on a desk as far away from the military as they can. Later when his homosexuality became public knowledge he became too big of a security liability even at that position. What if the Russians learned about that and blackmailed him into subversion?
Most importantly security is impossible on a VonNeumman machine because everything is on the same memory space. therefore the machine can't keep itself secure from itself.
This is absolutely not true. Today it is hard to find even a simple [ARM] micro without memory protection unit. It is typically not very capable, but good enough for most applications.
Higher-end MPUs and CPUs have very good memory protection mechanism. Go ahead and try to crash something other than your own application under any modern OS.
It is like saying C is not secure, lets all use LISP. There is a natural selection, and nobody wants LISP, however good it is at calculating a factorial.
Same goes for MCUs. What we have is probably not the best, but most definitely good enough. And any proposal that claims to solve all the problems at once is bound to fail.
There is a video on Mill Security which I found very interesting - not that I am an expert in any of this...
This is absolutely not true. Today it is hard to find even a simple [ARM] micro without memory protection unit. It is typically not very capable, but good enough for most applications.
Higher-end MPUs and CPUs have very good memory protection mechanism. Go ahead and try to crash something other than your own application under any modern OS.
It is like saying C is not secure, lets all use LISP. There is a natural selection, and nobody wants LISP, however good it is at calculating a factorial.
Same goes for MCUs. What we have is probably not the best, but most definitely good enough. And any proposal that claims to solve all the problems at once is bound to fail.
This has been proven wrong many times and it is also not very relevant in an age where hardware comes backdoored from the factory. Memory protection is at best a hack.
Turing and VonNeumann could have told you even back then the properties of a secure cryptographic or computational system. These properties are fundamental and if not observed no subsequent hack can remedy them.
1 -Cyphertext key and cleartext should never ever be stored in the same place. 2 - The only place these three come together must be in the cryptographic engine, 3 - which should have no persistent memory and should not be Turing complete. It should be a finite state machine with only enough states to let it do its job.
From this you can infer that no computer is fit for cryptography or security work because it is Turing-complete and also has memory.
You can extend this to imply that storing code and data on a Turing-complete machine is also fundamentally insecure. A Turing-complete system is incapable of keeping secrets from itself. You can't change this fact by merely writing more code for the Turing machine to compute.
The Berkeley architecture mitigates that to an extent but the mere fact that it is not the dominant architecture on the market today indicates that there are other non-scientific factors at work.
This also means that even with Berkeley architecture you still can not store the above three elements on the same machine.
Btw has anyone counted how many separate Turing-complete systems are there in a computer?
Have a look at the comp.arch archives. Ivan Godard has been very active discussing the reasons and consequences with a group of very experienced and knowlegable people. His answers are good and solid, but that won't be the determining factor in the Mill's success/failure.
Information has only been disclosed in dribs and drabs, after the relevant patents have been filed.
My opinion: very interesting, but we will see if it is ever built and used in anger. I would expect some of the patents to be licenced to manufacturers.
Search on YouTube for Ivan Godard and you will find hours of material from him on the Mill architecture, including a series of talks going though things in fine detail.
This has been proven wrong many times and it is also not very relevant in an age where hardware comes backdoored from the factory.
Actually it
is relevant because it shows that CPU architecture is not the problem.
Memory protection is at best a hack.
How so?
From this you can infer that no computer is fit for cryptography or security work because it is Turing-complete and also has memory.
Now you are talking about a computer
system, not the CPU.
Btw has anyone counted how many separate Turing-complete systems are there in a computer?
I'm not arguing against security, I'm arguing for sanity.
There is no way I'm going back to programming anything with Harvard architecture, so are 99.9% of the programmers. That's just too painful and impractical.
It is not an all or nothing situation, there must be a combined approach. Which is what we have right now and I really see no downsides.
One more thing on the Mill - it can't handle interrupts efficiently without extra hardware. Mill heavily relies on compiler keeping track of how many things are stored on the belt at the moment. Interrupts introduce uncertainty into that process.
Actually it is relevant because it shows that CPU architecture is not the problem.
Now you are talking about a computer system, not the CPU.
If you insist on making that distinction... On my part I don't know how to take an existing CPU and design a different architecture around it, so the point of the exercise is lost on me.
You must have noticed that I don't even distinguish between computers and cryptographic systems. From the information theory perspective they are governed by the same laws.
Memory protection is at best a hack.
How so?
The Red Pill Attack is an attack first demonstrated in 2006 by Joanna Rutkowska where a complete system working on the bare hardware is transferred to virtual environment without the system realizing it. It renders memory protection completely irrelevant.
This is only one in a long list of attacks that defeat memory protection. All in all leaving such a fundamental security task to the operating system is foolish, a hack at best, and completely inexplicable from security standpoint.
This is like leaving prison security to the filing clerk. It would work 100% if all prisoners were honest...
The Red Pill Attack is an attack first demonstrated in 2006 by Joanna Rutkowska where a complete system working on the bare hardware is transferred to virtual environment without the system realizing it. It renders memory protection completely irrelevant.
We are talking about different things. If x86 was Harvard, it still would be possible to get the image of the entire system and put it into an emulator. How does it solve anything?
You need a real hardware authentication method. That's what UEIFI and Secure boot are.
I think it is just very clear that HAL-42b does not work in, around, or anywhere near computer security in any sense of the phrase.
There is no way I'm going back to programming anything with Harvard architecture, so are 99.9% of the programmers. That's just too painful and impractical.
It is not an all or nothing situation, there must be a combined approach. Which is what we have right now and I really see no downsides.
One more thing on the Mill - it can't handle interrupts efficiently without extra hardware. Mill heavily relies on compiler keeping track of how many things are stored on the belt at the moment. Interrupts introduce uncertainty into that process.
Programming implies a Turing-Complete machine and language. What I'm saying is that if you want guaranteed security you should stay away from Turing complete machines. So no programming necessary
You can let your computer handle the cyphertext but the cleartext, the key and the crypto algorithm should reside outside of it on a non-Turing complete device with minimal capabilities. Something like the KYK-13 key storage device.
Non-programmable, simplistic machines have
never been compromised. Nope! Never. Not once in the entire history of security. In fact, I wouldn't have any relevant, specific experience with that! Nope. Not one bit.
That's what UEIFI and Secure boot are.
Those are not end user verifiable. They are good for Microsoft but don't do much for you as an end user. Coreboot maybe.
You can let your computer handle the cyphertext but the cleartext, the key and the crypto algorithm should reside outside of it on a non-Turing complete device with minimal capabilities. Something like the KYK-13 key storage device.
Ok, but how does bashing of the VonNeumman architecture come into play here? There are plenty of other security devices like that, just use them with whatever architecture you like. Mill does not solve any of this on its own and will still need external security devices, which is fine.
One more thing on the Mill - it can't handle interrupts efficiently without extra hardware.
Do you have a reference for that?
Many things about the mill are NYF (not yet filed), and I haven't been keeping up recently. As we all know, absence of evidence is not evidence of absence,
Do you have a reference for that?
I watched all of his lectures, and that statement is based purely on my understanding of the architecture. It is possible, of course, that they have thought this through, but I feel like they really did not and interrupts will be implemented as a hack with a separate belt, which will mean very inefficient communication between the main belt and interrupt belt.
They are not really sure how virtualization and context switching will work, that's is clear from Q&A. He just did not have a good answer for any this.
And you can stretch this "we have cool stuff, but patents are not filed yet" story only so far before you either need to start giving answers or stop promoting your stuff until you have filed for patents.
Right now it looks like "we don't know yet, but we'll think about it, file a patent, and tell you when its done".
If I should ever design my own CPU the most useful instruction would be
Halt and Catch Fire (HCT, 0x6666), just to have funnier talks when people will ask WTF is the reason for that
(three
characters typed behind the humor
in one video, Ivan Godard explained the euphemism
)
Ok, but how does bashing of the VonNeumman architecture come into play here? There are plenty of other security devices like that, just use them with whatever architecture you like. Mill does not solve any of this on its own and will still need external security devices, which is fine.
I'm not defending the Mill architecture. To me it is just a curiosity. The Harvard Architecture on the other hand is a marked improvement over the VonNeumman in terms of security.
VonNeumman has been tested in the real world and every aspect of it has been defeated comprehensively. It was built without any consideration for security and I assert this was known to its creators right from the start. At the time this was not important. A computer only did computations and as long as computations were correct there was no reason for concern. This has been perpetuated by the industry ever since then, trough the advent of the personal computers and later in the Internet age and to this day. Security was left to the operating system and then to third parties. You couldn't make it any worse if you tried.