Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • Christophe Biocca
    Participant
    Post count: 3

    4) Will all operations have the same latency across all Mill chips? Your examples have always had that multiply is a three cycle operation. Would a Mill ever be delivered with, for instance, a five cycle multiplier?

    It’s been mentioned in a few talks that the latencies are dealt with in the specializer, so they’re allowed to vary across members. I don’t remember off-hand whether any hardware instructions vary in latency, but binary and decimal floating-point were given as examples of code where the hardware implementation might not exist at all and the specializer would implement it in terms of a library call or inline instructions, effectively changing the latency of the operation.

  • Christophe Biocca
    Participant
    Post count: 3

    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).

  • Christophe Biocca
    Participant
    Post count: 3

    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”?

Viewing 3 posts - 1 through 3 (of 3 total)