Comment by willvarfar | Hacker News Reader

Comment by willvarfar | Hacker News Reader

Parent Full thread

(I'm on the Mill team :) )

Its good to see classic ISAs moving away from memory protection 'rings' towards arbitrary 'zones', even if retrofitting it e.g. SMEP/SMAP gives horrendous APIs and a nightmare to keep checked and balanced! ;)

The Mill comes at this from the other direction, starting with 'zones' (termed "turfs" in Mill jargon) and emulating 'rings' (if your kernel wants that) with overlapping access rights between turfs.

On the Mill you can have lots of turfs that may or may not have disjoint memory access, and you move between turfs synchronously with a special kind of indirect function call termed a "portal". There are provisions for passing across specific transient rights to memory in these calls, so you can pass a pointer to a buffer and other aspects that facilitate the 'usercopy()' mentioned in the article but with full hardware rather than software protection.

We have tightened the portal/turf concept extensively since the Security talk http://millcomputing.com/docs/#security but it does give a gentle high-level intro to turfs and portals.

These days, we have facilities for passing buffers without exposing memory pointers and other niceties to make it easy to write correct yet efficient code. They can now all be made public but oh so little time, and I'm hoping to get a white paper out about it by the end of this month. Watch this space ;)

Happy to elaborate if anyone has Mill or general questions :)

PS an example of 'zoning' is http://elfbac.org/ , which is not getting enough attention. Its another way facilitate memory separation, albeit by abusing the classic MMU and with inherent runtime cost. Elfbac is userspace, but the hardware could be abused to protect kernels on classic CPUs too. Well worth everyone reading :)

Can you give us any hint about how much time is there until we can buy a Mill to play with?

From that security presentation, I've left with the idea that you wouldn't want a Linux kernel on the Mill. You'll more likely want something smaller, with a Linux virtualization layer for device drivers. That's because your security layer is extremely flexible, making it possible to push a lot of kernel space code into some less powerful context while keeping performance the same.

So are you working on a Linux port for it? (Maybe breaking it in pieces on the process?) Or do you intend on starting with something else? (Maybe building up from a microkernel?)

I was excited about the Mill when I first read about it 5 years ago. But at this point is there any reason to believe I'll ever get to write code for one? (Even via an emulator or something like that)

(I can't/won't watch videos, so will have missed anything that was only in videos)

We are completely serious about building it. We are working hard towards that goal. The team is 90% industry vets with very long careers designing and making real chips in devices that really ship and are really still used in their billions today, so we know what we're doing and just how long its going to take. We're bootstrapped so we can't complete with chipzilla on timescales, but we really desperately want to get Mill goodness out there as quick as humanly possible :)

we know what we're doing and just how long its going to take

So... how long is it going to take, specifically?

Chisel isn't that hard.

Can we test it out on an FPGA?

The official AARCH64 emulator is a Linux binary-only application. I would be happy to play with a Mill equivalent.

>(I can't/won't watch videos, so will have missed anything that was only in videos)

There's something like 15 hours worth of talks on the Mill. If you don't want to watch any of them then you're missing out on most of the design of the Mill.

Even if the Mill never gets to see the light of day, the talks were quite interesting IMHO.

It's not a Mill-specific. I'm happy/frustrated to hear that these talks are good but that doesn't change anything. I figure/hope that for anything important/valuable enough someone will eventually write it down.

It would help if the Mill people wrote a peer reviewed paper and produced a lower case ultra small font mVP that people could actually use.

I've been hearing Mill stuff since 2012. They had a weird non LLVM/GCC sorta kinda compiler port. Today in 2016, the toolchain support for way Out Of The Box stuff is great. They could do an LLVM port and a Chisel simulation and have Linux on top of that. But instead we get

  The team is 90% industry vets with very long careers

And no, I'm not going to watch 15 hours of Ivan Godard whinging on. Get off the pot and produce something.

I'm rooting for you guys, I want to buy one! Maybe do a kickstarter once you have a stable chip that could be manufactured?

Looks pretty cool. Out of interest, have you considered adding support for something like the enclaves provided by Intel SGX, e.g. for cloud computing use cases?

Yes, although we put that into our "virtualization" bag which we haven't begun mapping out in detail yet. I do try and keep up with the SGX roadmap and exploits; there have been some truly awesome attacks on it via hyperthreading, for example :) It will be interesting to see what AMD Zen does in this direction too. When the Mill is made, there will be all these orthogonal systems needed for these kind of use-cases available, but they won't pollute the portable ISA proper.

Reply on news.ycombinator.com