[willvarfar]

Excellent point! I really hope such a sensible suggestion is added to mainstream compilers asap and blessed in future standards.

Apologies to everyone suffering Mill fatigue, but we've tried to address this not at a language level but a machine level.

As mitigation, we have a stack whose rubble you cannot browse, and no ... No registers!

But the real strong security comes from the Mill's strong memory protection.

It is cheap and easy to create isolated protection silos - we call them "turfs" - so you can tightly control the access between components. E.g. you can cheaply handle encryption in a turf that has the secrets it needs, whilst handling each client in a dedicated sandbox turf of its own that can only ask the encryption turf to encrypt/decrypt buffers, not access any of that turf's secrets.

More in this talk http://millcomputing.com/docs/security/ and others on same site.

[PhantomGremlin]

> we have a stack whose rubble you cannot browse, and no ... No registers!

Wow. There's the Wheel of Reincarnation [1] in action. The Intel iAPX 432 microprocessor had similar ideas.[2] E.g. no programmer visible general purpose registers, "capability-based addressing" to control access to memory.

That was a mere 30+ years ago. Let's hope you're more successful than they were.

[1] http://www.catb.org/jargon/html/W/wheel-of-reincarnation.htm... [2] http://en.wikipedia.org/wiki/IAPX432#Object-oriented_memory_...

[ams6110]

If I'm understanding the idea, this reminds me of the processor in my first computer, the TMS9900 used in the TI-99/4[a] computers.

This processor didn't have general purpose registers, it had "workspaces" in RAM that served as register sets. The processor had a workspace pointer register that pointed to the workspace currently in use. This was cool because it meant that a context switch could be achieved by just changing the workspace pointer. However the downside is that RAM access is slower than register access.

[ChuckMcM]

They were cool. That processor is fairly maligned in my experience but it had some solid ideas. I built a CPU in an FPGA that used a construction similar to a cache line to hold registers as an experiment once. The one line (64 bytes) was 'reserved' for 16 registers (8 GP, 4 index, and 4 process specific (SP, PC, STATUS, MODE)), a context switch reloaded the registers as it reloaded the cache. That made context switching a bit faster than a full on push/pop stream but not as fast as having dedicated register banks ala SPARC.

These last two posts by Colin though really got me thinking about the who push for a 'trusted computing base' that folks had back in the 90s. Basically the same argument was used then to justify specific hardware as part of the system for implementing the crypto bits. At the time I thought it was overkill but I can see now how such a system can contain implementation faults into more detectable domains.

[cperciva]

Just wondering, have you talked to the CHERI people? It sounds like there is a lot of commonality of interests there.

[willvarfar]

I've been following them but we haven't talked. Yet :)

[polarix]

What's the current status of the Mill project? Is there a proof of concept compiler / emulator? What's the bootstrap strategy to get things rolling?

[Symmetry]

Last I heard they're still limited to sims and are concentrating on patent filings. The bootstrap strategy is LLVM (once they get around LLVM assuming addresses are integers as opposed to the Mill's compound things) and to get Linux running on top of L4 which seems doable[1]. They say they're looking for a niche to start in before going after PCs.

[1]http://l4linux.org/

[xorcist]

Why on L4? Is Mill somehow tied to it, architecture-wise? Or is it just that L4 has a smaller footprint and is easier to port?

[willvarfar]

Its about footprint. We certainly will run Linux on the Mill, but its work we don't have to put on the critical path. L4 is just a familiar lightweight OS, and we're keen to play with Mill-specific security features which are particularly applicable to microkernels too.

When we do port Linux, I expect it to become much more microkernel like, as in why would you want your disk drivers to be able to read write video memory etc?

[xorcist]

> why would you want your disk drivers to be able to read write video memory etc?

That is a much bigger issue than the CPU architecture, as it has more to do with how the peripheral hardware works (firmware, DMA, etc.), but I appreciate the effort.

[willvarfar]

Well its how the CPU architecture exposes the hardware to software i.e. drivers. The Mill does MMIO but doesn't have rings.

[Symmetry]

Because the Mill has a single address space with memory protection, which works a lot better with L4 than it does with Linux. Porting Linux directly would probably be possible, but a huge effort the team wouldn't be able to pull off without a lot of extra resources.

[willvarfar]

We are hard at work :)

There is no public SDK yet, and hardware is also under development.

We've had a simulator for a long time, and we show it off a bit in the Specification talk:

http://millcomputing.com/docs/specification/