virtual 256-bit SASOS capability system

[David Nicol]

I haven't really settled on a name for the system I've been designing and occasionally talk about on this list. Reading the benefits from Coyotos being a SASOS was certainly part of the inspiration. Let's call it SASOS256 for this conversation.

It isn't tied to any particular hardware, and I recently worked out how to have an identifier for a Lambda that is not dependent on a particular runtime platform, which is to use an identifier derived from the Identity of a human-readable contract that says what the method is supposed to do, plus the Identity of a particular runtime, to identify "how to do method M on my platform, if someone has already compiled it for me". 

All the identities are 256-bit hashes. I'm using Blake3 because it's faster than SHA-256 but either would work.

Cryptographic signing using ed25519 (also, 256 public keys, and signatures) is how policy decisions are made, including a robust and transparent revocable delegation system to answer "does identity I have the right to do thing T?"

The only Big Secret that has to be kept is private keys, so the software that runs SASOS256 and the software that does signing are kept separate, air-gapped or as close as we can get for a given purpose.

"Meaning" derives from contracts and contract terms; implementation details are implementation details; the result is supposed to be a widely distributed general purpose virtual machine that can do all the usual stuff.

Thoughts? Anyone care to help? Questions?

--

"Plot complication appearing on sensors now"

[Jonathan S. Shapiro]

David:

Given the discussion about why Coyotos shouldn't be a SASOS, is it still a source of useful inspiration?

Jonathan

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO9PeG2DhtHqaVTaT9HpDdX4jymVUF%2B-bxajg4V%2B_P0R6w%40mail.gmail.com.

[David Nicol]

At a conceptual level, yes. SASOS256 isn't constrained by particular hardware until it gets instantiated/expressed as such.

"coyotos on x86-64" which is what you're talking about is so constrained.

There's a philosophical detour available into what constitutes an "address space."  The x86-64 architecture provides its

own onion of addresses relative to address spaces, and the reasons that onion exist certainly apply to your project.

Within SASOS256, there is such an onion as well, running simultaneously with content addressability and using

the same ample 256-bit address space for the identifiers, but extended addresses use two of the 256-bit atoms.

Immutable a/k/a "content-defined" addresses are simply the hash of the content octets, and are always one atom.

Mutable addresses carry "meaning" and SASOS256 defines a discipline of concat(topic, aspect) as how to create such addresses.

For instance, a local runtime could define a topic that means "all information associated with this topic is private

so we don't share it with other runtimes and we don't even share the address of the topic with other runtimes, so

we can trust that we are the only context that can either write or read aspects of this topic" which essentially turns

the topic into a read/write capability on all L-values associated with the topic, without bothering with safeguards

against deliberate attack via methods that cheat by observing virtual bus behavior and so on.

Letting capabilities be addresses in the same space as everything else creates a "copy vulnerability" even if 256-space

is large enough for "guess vulnerability" to be unworkable. "Access a specific unsigned mutable" seems like the

smallest-grained deniable privilege in an access control system, for both read and write access, separately or bundled.

If the system has a reliable membrane around it preventing attackers from inspecting the internal state, topic address

secrecy is sufficient and access control list checking isn't needed. Without an opaque membrane, the operation delivering

unsigned mutable functionality will need to check for membership of the source of the read or write message in

an allowed-sources set. Assuming an opaque membrane certainly simplifies design greatly.

Some mutable addresses are cryptographically signed, such that all L-values the holder of a secret key may modify

are addressed with concat(public key, salt) where salt is a meaningful identifier. This makes the write operation the only

operation restricted at an ontic level: knowing the secret key implies capability to replace the value of a signed mutable.

"meaning depends on context" seems axiomatic in discussions of authority for meaning.

"Coyotos on SASOS256" could be a worthy thought experiment, for nothing more than getting clarity about where

the authority boundaries are in the swizzling/unswizzling operations, and the boundaries between installed Coyotos

installations. In the original SASOS Coyotos, which was designed without hardware-provided privilege features

as I understand it, the system addresses were shared over all installations, right? In SASOS256, an implementation 

of an x86-64 emulator would have a Word256 that could be applied to a content-derived address to essentially

boot up the machine. For practical purposes, it would probably be more useful to provide a suite of Word256 operations

(a/k/a Op256 methods) that allow specifying an execution context conforming with a known OS, allowing running

unmodified foreign executables.

Am I making sense?

David