Inter-process Communication

As far as the wiki is concerned, whether a call is a portal call or a regular call is not determined by the caller (both use the same call opcode). Portal-call vs. in-turf execution vs. fault is determined by the
permissions of the calling turf on the entry point of the called code.

In addition to the above, a turf can grant/revoke portal/execute permissions on their code to other turfs, as a way to achieve microkernel-style privilege separation.

This protects the caller, but the callee can’t know for certain that the foreign code they’re calling into will actually run in a different turf. I could write an evil portal service that grants plain execute to would be callers, and they wouldn’t be able to tell.

Am I missing something? Is this just a matter of policy (always have a separate, trusted, turf control the portal permissions so that you can trust that they’re set properly and never changed out from under you), or is there a way for a caller to say “this must be a portal call, fault otherwise”?

• This reply was modified 6 years, 10 months ago by  Christophe Biocca.

And the attacker cannot blindly give such rights to the victim; there is a check so that a suspicious victim must accept a proposed grant before it takes effect.

That does solve the issue I had in mind: the attacker granting execute instead of portal permissions to its own code, the victim, unaware of this, calling into it and giving attacker-controlled code in-turf access.

Making each grant subject to approval does solve this issue, and means the program can simply check a purported portal call address once (to not have execute permissions at all) and use it safely afterwards. Then even revocation of the portal permission wouldn’t later cause problems for the program (beyond faulting).

Can you compare your ideas behind IPC to the seL4 operating system, which is the first operating system that comes with proofs of correctness (including proofs that the compiler correctly translated the code to assembly!). Awaiting features from CPU vendors, they are also on the cutting edge of doing time-dimension proofs. The feature that I see seems lacking on seL4 is futex(), with all its security coming from the page tables and seL4’s existing memory type system, but otherwise everything both you and seL4 seem to be talking about is properly utilizing the MMU to its full potential.

OK, I just watched the whole video. I would love to be part of supporting/developing the C API on top of turfs[1], as I think this is really cool. One question stuck out, which is that you say you have global addresses and the TLB *after* the cache, and then you say you have a local bit. But if the local address space is 60-bits you would have to put a TLB *before* the cache to support local addresses. Why not instead shrink the local address space to something smaller like 32-bits (convenient because applications generally have to support 32-bit arches, so you can just compile apps in 32-bit mode), and then just implicitly fill in a zero top with the thread+turf id, and thus preserve the global address space model, while still supporting the local addressing abstraction?

[1] As you pointed out, the C API is insufficient, because there is no concept of a slice (pointer and length, with constant property) to transfer address space.

Ahh, I guess I answered my question. You want the Mill to support existing code, and quirks are a great way of turning people away, and plenty of existing code needs more address space than 32-bits. And later you could release a Zinc that only support 32-bit addresses in the local address space.

> such as a MMU

You still need something to enable de-fragmentation, and that same machinery would give you the ability to implement CoW for fork(), and perhaps sparse maps.

I am talking about having a 32-bit addressing mode on a 60-bit mill, for performance/memory/cache reasons.

There’s two kinds of potential fragmentation: of the physical memory space, and of the virtual address space. They are tied in a legacy architecture, but separated on a Mill. The physical space is managed by the TLB, which can do paging and physical consolidation in a manner very similar to a legacy. In contrast, the virtual space is never consolidated; this is a consequence of the fundamental design choice to have caches in virtual.

There’s no obvious advantages to having a 32-bit virtual space in a 60-bit physical space. True, pointers would be four bytes rather than eight, but one can use 32-bit indices just as easily. There’s the problem of programs that need more than 4G, but those could use large mode. But the big problem is mixed mode. Sandbox code will need to use facilities from outside the sandbox, and those would be reached by 8-byte addresses. Keeping track of near-vs.-far addresses is something that we left behind with the 8086.

So yours is an interesting question: could it be done in the hardware? I think the answer is yes, the hardware could do it. But it would cause a great gnashing of teeth, both among our software teams and customers that used it. Would it sell enough more chips to justify the pain? I don’t think so.

hi mill team,
i have a question about the transient grant.
if A calls B via the portal, it can grant B permission to a memory area via pass. if the thread comes back, this permission is revoked – right?
but if B wants to return a memory area to A, how is this managed? does B have to order a new memory area and pass it to A?

> Caller and callee can share an allocation arena set up in advance and used for multiple calls.

You could return a read-only grant to found data, because those grants have byte-granularity.

And a filesystem daemon could also provide shared mmaped files in the direct VM space (instead of process-specific VM space).—hmm that wouldn’t work. How can IPC use the same parameters both when passing by copy and through zero-copy (VM manipulation)?

• This reply was modified 4 years, 1 month ago by  ShawnL.

When performing IPC, how does the caller specify how many return values to expect from the callee?

For example, let’s say that the caller expects the (untrusted) callee to return exactly one value. If the callee ends up returning two values, then both values would end up on the caller’s belt, and it would interpret the first returned value as the return value of the function and the second return value would be interpreted as the result of a previous instruction, right?

How does the mill’s IPC mechanism work around this?

Thanks!