Mill Computing Blog

You must be astroturfing (or whatever it's called - submarining, secretly shilling, etc.) for the Mill project[0]! ;)

Every once in a blue moon someone from that group returns from "investing sweat equity into patents" (or however they're [not] getting paid for whatever they're doing) to HN's reality distortion field (welcome!) and blesses us with wisdom[1] from their awe-inspiring project currently classified as vaporware by many such as myself with no public evidence of even a single physical hardware prototype.

I would be interested to hear your thoughts about that project, and also hope my playful jab (not too harsh?) can provoke any of them to respond to your comments (maybe they should hire you!). There are other projects mentioned in those comments that you may find interesting as well (CheriBSD, L4 Linux, etc.)

Also, any thoughts you have time to share on the adaptability of the various open hardware RISCV projects, which seem to be at the beginning stages of delivering just beyond basic functionality without much priority allocated for your secure performance concerns. I was surprised to see no specific mention of it in your initial​ comment.

To the best of my very limited knowledge, a genuinely secure processor, even versus nation-state level actors, is unfortunately still non-existent or near uselessly underperformant (is that a word?) at this point. Not to mention all of the various other, often easily side-channel attacked, bits and pieces are required to…

What excites me most about RISC-V is the ability to potentially experiment at a systems level. I love the Mill project and they have a ton of interesting and clever ideas but they're trying to innovate along so many dimensions at once that I feel like it's almost a forgone conclusion that they'll fail. What I'd really like is for someone to design a chip with their ideas about backless memory and putting address translation at cache/memory border and do a RISC-V implementation of that. Then you could try getting a working OS with that up, and then maybe incrementally try out other ideas rather than just trying to change the world all at once.

We've had this paradigm about how memory and permission and OS resource management works that we've have since the PDP-11 and I think we ought to be looking at how to move beyond that.

http://millcomputing.com/wiki/Memory

Talks on the Mill CPU architecture:

https://www.youtube.com/playlist?list=PLFls3Q5bBInj_FfNLrV7gGdVtikeGoUc9

See also:

https://millcomputing.com/docs/

Ivan Godard is a pretty good speaker, and his discussion of how the Mill CPU works is very insightful if you are at all interested in modern CPUs work.

I don't know that we'll ever see Mill CPUs in wide use (I've been focusing on RISC-V), but there are so many interesting ideas presented in this video series. Ideas that will leave you asking: "Why do we do things the way we do now?" over and over again. One of the most interesting ideas is how the Mill CPU architecture takes into account the 2D nature of silicon lithography.

Why do you think such an architecture is completely invulnerable? The Summary #2 slide lists the following as a benefit of the Mill:

- Can load across protection boundaries
Valid data is usable; invalid data cannot be seen

At the very least, this probably makes ASLR pretty easy to defeat across protection boundaries. Are you really willing to bet that there will never be a more clever exploit that can determine more information? In slide 51 of the IPC talk[0] they explicitly say that they put permissions checking after the cache, and that this is essential for their performance and power claims.

[0] https://millcomputing.com/docs/inter-process-communication/

I kept reading but I did have a "hey, that's kind of unfair" reaction at that line. It's not their fault that the speed of light is a hard limit, eh?

There's a chicken and egg problem with compilers and languages on the one side and machines architectures and instruction sets on the other, it's not easy breaking the mold. (GPUs are a counter-example perhaps?)

CPU designers can't all be Ivan Godard ( https://hackaday.com/2013/08/02/the-mill-cpu-architecture/ https://millcomputing.com/ ) or Chuck Moore ( https://en.wikipedia.org/wiki/Charles_H._Moore#Hardware_design http://www.greenarraychips.com/ ) eh?

I should also have mentioned The Mill architecture as an example of dealing with code as blocks of instructions instead of each one separately. In this case they get a higher fetch rate for their VLIW machine by starting execution from the middle of the block and fetching both up and down at the same time. So they have two program counters which get set to the same value on every jump or call.

https://millcomputing.com/

The point is that inside every advanced processor instructions are handled in groups and if you expose that to the compiler you can save transistors and energy.