On Saturday, August 7, 2021 at 2:50:53 PM UTC-5, BGB wrote:
> So, I guess I can note something:
> When I had switched over to the newer "ringbus" design, one side effect
> was that the MMU had gotten broken (though I didn't have everything
> stable even before this).
>
> I have since gotten around to fixing a lot of this so that the MMU now
> works again.
>
> Have gotten a few other things written:
> Volatile cache lines, which are auto-evicted after a few clock-cycles;
> Logic to enforce Read/Write/Execute on cache-lines;
> Inappropriate access will result in a CPU fault.
> Decode-time logic to disallow using certain instructions in user-mode;
> ...
>
> Some features, like memory access protection, are currently only done if
> the MMU is enabled. Otherwise with the MMU disabled, the whole address
> space is accessible in user-mode.
>
> The restrictions on which instructions and which control-registers are
> allowed is enforced in the instruction decoder, which in turn depends on
> the mode bit in SR (which is Read-Only in usermode).
<
Quibble: If the user can "see" the mode bit, the a virtualized OS can detect
that [s]he is being virtualized.
<
> This does mean that
> changes to the mode would require a pipeline flush to take effect,
<
No, you just have to insert the mode bit with each instruction as it enters the
pipe. Then you can change the mode bit every other instruction--should you
desire. This is the means for executing multi-threads where each thread can
be in a different mode.
<
> but
> given that the main way for exiting or returning to usermode would be
> via an Interrupt or RTE instruction, this is not likely an issue.
>
>
> Access to the Keyring Register (KRR) is also disallowed in usermode,
> since it is assumes that usermode code is untrusted.
> Code in supervisor mode will have access to KRR, in which case any use
> of keyring checks in supervisor mode would be based on the "honor system".
>
> For kernel code and drivers, having KRR accessible should be OK assuming
> non-hostile code.
<
Most drivers, and huge swaths of the OS should not ever need to look/modify
the keyring. So, even if you trust them "a little" you might not want to trust them
completely. Can you think of a driver that does need access to KRR ?
Read access ? write access ?
>
>
> Could in-theory add something akin to the 4-level protection rings in
> x86, but can't really think of any way to protect keyring access in
> kernel mode that would allow kernel code to still do its thing without
> also being trivially bypassed (thus defeating the whole point of trying
> to protect it).
>
> The only way to meaningfully protect the keyring from drivers would also
> (effectively) mean running them in user-mode (but maybe add a partial
> split between "User Mode" and "Superuser Mode", with the latter mostly
> intended for running drivers and similar).
<
It is reasons like this that both Mill and My 66000 have no privilege--we
just have MMU and each "thing" runs in its own protection domain which
is setup by someone who has the required trust.
>
> So, by the time there is hostile code running in kernel mode, everything
> is basically "already hosed" as it were (and there would be no point in
> adding additional protection rings).
>
Yep, this is why the old systems (x86) have added a secure mode (circa
2006) and are now trying to add another mode (2020) and will be adding
a still 'nother mode circa 2026. The way they ar going there is no end to
the additions...........
>
> As noted, for now I only have two levels:
> Supervisor Mode: Can do pretty much anything it wants.
> User Mode: Can basically do stuff relevant to user-level code.
<
Mill & My 66000:: a thread can only touch things for which the MMU
grant access. There are no privileged instructions or modes or .....
<
(I don't remember about Mill) But My 66000 allows access to processor
control registers via memory the location of which is determined by a
PCI-configuration access page. Thus, there are not instructions to do
this stuff and everything goes through the MMU via LD and ST.
>
> Then, Supervisor mode effectively has two sub-modes:
> ISR Mode: SR.MD, SR.RB, and SR.BL Set;
> Kernel Mode: SR.MD Set, SR.RB and SR.BL Clear.
>
> And user-mode:
> User Mode: SR.MD, SR.RB, and SR.BL Clear;
> Superuser Mode (?): SR.MD is Clear, SR.RB is Set(?).
<
modes after modes after modes,................that is the old way of doing things.
>
> Superuser mode means slightly tweaking a few things, and works on the
> assumption that one can't be simultaneously in an ISR and also in User
> Mode. In terms of operation, it could be a "slightly less restrictive"
> version of normal user mode (specifics here are still TBD).
>
>
> The Keyring system is, as noted:
> Each page may have a VUGID pair, and User/Group/Other flags;
> Each thread may have a Keyring register, with up to 4 keys
> Though, this could be potentially expanded if needed (*1).
>
> So, as noted, access to a page is based on having a key in the keyring
> which grants a certain level of access.
>
> *1: It is possible that I could expand the keyring to 8 or 12 keys if
> needed (via the use of additional registers).
>
>
> Another recent change was that the key can now be interpreted as either:
> 64 VGID, 1024 VUID (Default)
> Or:
> 1024 VGID, 64 VUID (Alternate)
>
> Though, if going "mix and match", it would be necessary to assign pairs
> such that there are not unintentional overlaps (such as not allowing the
> same number to be used as both a VGID and as a VUID within the other space).
>
> Say, for example, VGIDs are assigned in decrementing order, and VUIDs in
> incrementing order, such that there is a low probability of clash (or at
> least until the numbering space gets full); though with the special-case
> exception that "0/0" is hard-wired as the "VUGID Root".
>
>
>
> Another thing I had looked into before was Capability Addressing,
> however, lacking with this is a good way to implement it which is:
<
> Straightforward to implement;
> Affordable (for both hardware and software);
> Plays well with C;
<
The plays well with C part is going to require a <near> complete 64-bit VA space.
<
In My 66000 the HoB of the VA selects between Portholes (1) and normal
memory (0). Normal memory is translated in a way similar to what we have
been doing since the days of S/360/67 (page tables). Portholes are a 4
doubleword PTE that contains a root pointer to another address space,
and a base (lowest addressable byte) and limit (highest addressable byte)
and addition access rights (restrictions).
<
Mill uses the HoB, also, but I forgot the mechanisms.
> ...
>
> Ideally, whatever mechanism is used should be "mostly invisible" as far
> as normal user code is concerned, which limits the use of addressing
> modes which are not (or do not appear as) linear pointer-based addressing.
>
> Similarly, enforcing "memory safety" is a non-start for C, and requiring
> the use of some other "memory safe" language, is also a bit lame. A
> better option would be one where even actively hostile C code can't
> break out of its sandbox (while still allowing it free reign over
> whatever memory it "owns").
<
"owns" or has been lent--like via portholes.
>
>
> One possible alternative to capabilities (the poor man's version) could
> be, rather than having a special-purpose cache/memory for them; The
> address space is made "particularly gigantic", and a sort of
> cryptographic ASLR is used to make it "nearly impossible" to guess
> memory addresses to things one doesn't already have a pointer to.
<
ROOT pointers are the equivalent of the huge ASID.
>
> Say, for example, if stuff is randomly distributed within a 112 bit
> address space via a cryptographic RNG, then the chances of being able to
> guess the address of something one doesn't already have the address of
> is a bit of a stretch.
>
> Though, this does have the weakness that, in a high-level sense, this
> doesn't offer any additional protection by itself over a traditional
> MMU; and does have costs in other areas (eg: pointers and intptr_t would
> be 128 bits). Similarly, it would already be "fairly difficult" to guess
> addresses with ASLR within a 48 bit address space (and this is not a
<
Say you could perform said guess--the MMU should still prevent your guess
from becoming accessible !! There is a porthole protocol, and if it is not
followed precisely, you get no access whatsoever.
<
> problem easily subjected to a brute force search; so in practice the use
> of ASLR in a huge 112-bit address space wouldn't necessarily gain all
> that much over ASLR in a 48-bit space).
<
Don't be subject to the guess! If the porthole is not created and passed
and then installed precisely via the protocol, the attacker gets nothing
(zero, nada, zilch).
>
> Similarly, there is a lot of C code that would not likely respond well
> to suddenly having "void *" and "intptr_t" expand to being 128-bit types
> (even if it otherwise handles the 32/64-bit transition well), so as a "C
> friendly" option it would still be a little weak.
<
I made it work in 64-bit VA, so did Mill, so can you.
>
>
> It would also have the issue of basically making the L1 caches and TLB a
> lot more expensive (also also eat a lot more registers by requiring the
> use of paired GPRs for memory addressing, ...).
>
> Well, excluding a further "poor man's" option of only supporting 48-bit
> addressing in hardware, and then faking the 112-bit addressing via
> runtime calls and software emulation (and probably requiring 128-bit
> pointers to be declared like "int __far *obj;" or similar).
>
>
>
> Granted, within an "actual" capability system, there is still the
> problem that there is no good way to grant a capability to one part of a
> program without also granting it to the whole program (or, preventing
> hostile code from being able to "steal" access to something from a
> library, by being able to figure out where the desired capability
> descriptor is stored in a library's data sections).
<
All capability systems have the ability to downgrade access rights when
passing the capability to another. So should yours. In My 66000 I also
have the ability to instantaneously remove accesses to every capability
pointing into a thread's VA when the thread dies and when it removes
pages from its address space. The capability is translated THROUGH
the page tables of the owner's tables.
>
> This could at least be hindered by the use of intra-binary ASLR (or
> compile-time ASLR), so multiple builds of the same binary would have
> different memory layouts. However, untrusted code being able to gain
> access to any debug metadata for the library would defeat this. Within
> the program loader, it could also make sense to randomize library
> indices within the PBO ABI, ...
<
Unnecessary when you get the rest of the mechanics properly defined.
>
>
> I have experimented with some of this, but compile-time ASLR is not
> enabled by default because this makes debugging harder (some types of
> otherwise-deterministic bugs get turned into heisenbugs).
>
> Memory ASLR isn't really used much either, since this is only really
> viable when one has working support for virtual-memory, which is still
> an ongoing sub-project.
>
>
> This latter point is at least possible with keyrings, if there is a
> mechanism to allow a thread to temporarily gain or lose keys (likely
> involving the use of specialized system calls). The system call could
> validate a request and then add the key to the keyring, with the keyring
> reverting to its prior value once the scope in question exits. Threads
> would also have an initial keyring.
>
> One likely possibility is that the ability to request a given key would
> be assigned to a given binary image, and could potentially be wrapped as
> part of the "dllexport" mechanism.
>
> Ideally, one wants to try to limit how much any C code needs to know or
> care that such a thing is going on, so by default it would be hidden
> away as part of the ABI. In C land, code would then assume that pointers
> "just work" ideally without needing to know or care that a function call
> has crossed between protection domains.
<
The only thing a C program needs to know about Portholes is how to
create one (like MMap), and how to take a passed porthole and install/
deinstall it in his VA map. (C++ is better here as constructors and destructors
can do the install and deinstall).
>
>
> I am not sure if there is a formal overlap between keys and
> capabilities; a key could be considered as a sort of capability applied
> over a range of memory objects, rather than a single object. But,
> interpreting it this way seems like possibly a little bit of a stretch
> (given the mode-of-operation for the keys is a bit different).
>
>
> A lot of this still needs a bit more work though...
>
>
> Any thoughts?...