On 2024-03-13 2:29 p.m., BGB wrote:
> On 3/12/2024 10:31 PM, Robert Finch wrote:
>> Can capabilities be applied to address ranges?
>>
>> Segmentation similar to the PowerPC 32-bit segmentation is being used
>> in the current project. Where the upper address bits select a segment
>> register which provides more address bits. I would like to use the
>> same descriptors for capabilities and the address range segmentation.
>>
>
> Something like a segmentation scheme could also work.
>
> Though, these seem like two different approaches, so there wouldn't be
> as much value in a shared descriptor. Segmentation also tends to be more
> coarse grained, rather than something applied to individual memory objects.
>
Segmentation and capabilities look similar to me. They both have base /
bounds and permissions / access rights. The difference is the capability
carries along the pointer value and a segment descriptor does not. There
is the object type too, more specific than just code or data.

> Of these two, I am left to suspect that segmented addressing may
> actually be the less painful of the two...
>
>
>
> But, yeah, I was looking into a possible "Bounds Check Enforced" mode:
>   Will require using XMOV.x instructions to access memory;
>   Will check and enforce the use of tag bits.
>     The tag bits will be ignored in the normal mode.
>
> ISA level changes:
> Will need a flag-bit, and a few more instructions for working with
> pointers / capabilities;
> Will require a Tag-RAM area in DRAM.

One thought I had was to use whole bytes instead of just a tag bit. That
would make tag "bits" accessible with regular load and store
instructions. But also had considered using a second bit to indicate a
pointer store for garbage collection. If using one bit, why not use two?
One BRAM can handle a lot of tag bits.

>
> If the enforced mode is not supported, probably setting this flag will
> be No-Op, and the Tag-RAM will not be used.
>
>
> Micro-arch changes:
>   Registers are extended from 64 to 66 bits;
>   Load/Store operations also have 2 extra bits;
>     Will only apply to 128-bit MOV.X and XMOV.X ops.
>   Most operations will just set these bits to 0.
>
What is the second extra bit for?

> Unlike in the normal memory protection, handling of capability
> enforcement will be done in the EX-stage logic, rather than in the L1
> cache.

Hm, I was going to handle capabilities in the MEM stage logic.
>
> Other effects:
> ISR handling will now need to be more careful so as to not mess up the
> tag bits for registers (specifics TBD);
> The role of GBR/GP will need to be moved over into a GPR.
>
> May or may not consider making the register tag-bits accessible to
> privileged code as CR's, but this is likely to have a higher cost. The
> currently considered option is to have the ISR handler save the
> registers with MOV.X instructions and then copy the corresponding
> register tag bits out of Tag-RAM (and then restore these bits before
> restoring the registers), but this will be fiddly.
>
>
> Thus far:
> Of the parts added thus far, seems to have a fairly small impact on LUT
> budget.
> As for whether or not this idea will be DOA, this is yet to be seen.
> It requires effectively reviving the 128-bit ABI, which was also another
> likely DOA feature.
>
> Only real incentive is for untrusted code, where security is more
> important than performance (and one can live with a world where
> integer->pointer casting is either not allowed or painfully slow, ...).

In the document IIRC they said performance was an issue for capabilities
in the past. Implying maybe that with the performance of a modern
machine it may not be as painfully slow. Having an MMU was painfully
slow too, adding a clock cycle onto all the memory access.
>
>
> More likely, the use of optional bounds-checking with 64-bit pointers
> will remain as the more practical option, with the MMU and ACL checks
> serving as the primary security mechanisms.
>
> ...
>

>
> In the past, capability machines wanted to use capabilities for all
> relocation and all protection. As long as this is the case, an applica-
> tion has an unbounded need for capabilities.

It seems like it would have a lot of overhead, but it might be worth it
for security.
>
> You can grant this with limited capabilities (top 4-odd bits) only when
> you have a means to load a new capability into a known <capability> base
> register[i]. Since this is privileged data, either the specified function-
> ality of this instruction is precisely specified and operates with
> access to GuestOS address space.....it is difficult to imagine how to
> add Hyper-
> Vision on top of GuestOS supervision.
> {{Or do you intend to void Hypervisors?}}

I got the impression that with capabilities processor modes may not be
necessary. I think the distinction between hypervisor / supervisor may
be lost. Not sure that is a good idea.

On Wed, 13 Mar 2024 18:43:59 -0400, Robert Finch wrote:

> I got the impression that with capabilities processor modes may not be
> necessary. I think the distinction between hypervisor / supervisor may
> be lost. Not sure that is a good idea.

It gets rid of the hierarchy, and replaces it with a matrix.

Robert Finch wrote:

>>
>> In the past, capability machines wanted to use capabilities for all
>> relocation and all protection. As long as this is the case, an applica-
>> tion has an unbounded need for capabilities.

> It seems like it would have a lot of overhead, but it might be worth it
> for security.
>>
>> You can grant this with limited capabilities (top 4-odd bits) only when
>> you have a means to load a new capability into a known <capability> base
>> register[i]. Since this is privileged data, either the specified function-
>> ality of this instruction is precisely specified and operates with
>> access to GuestOS address space.....it is difficult to imagine how to
>> add Hyper-
>> Vision on top of GuestOS supervision.
>> {{Or do you intend to void Hypervisors?}}

> I got the impression that with capabilities processor modes may not be
> necessary. I think the distinction between hypervisor / supervisor may
> be lost. Not sure that is a good idea.

Hypervisors are absolutely necessary if you want high RAS where a GuestOS may
crash without taking the system down. Does GuestOS use capabilities supplied
by HyperVisor for which it has no visibility ?? just prescribed uses ??

Consider a ECC error in a Capability and someone trying to use it.
Is the error charged to GuestOS who owns and manages the capability ??
or the application who is only following the prescribed uses of the
capability ?? {{The "why shoot the messenger/innocent" problem.}}

On Wed, 13 Mar 2024 23:18:37 +0000, MitchAlsup1 wrote:

> Hypervisors are absolutely necessary if you want high RAS where a
> GuestOS may crash without taking the system down.

Not really. Remember, the whole point about introducing memory protection
into multitasking, multiuser OSes in the first place was precisely so that
one program could crash without taking the system down.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 13 Mar 2024 23:18:37 +0000, MitchAlsup1 wrote:
>
>> Hypervisors are absolutely necessary if you want high RAS where a
>> GuestOS may crash without taking the system down.
>
>Not really. Remember, the whole point about introducing memory protection
>into multitasking, multiuser OSes in the first place was precisely so that
>one program could crash without taking the system down.

Actually really. And modern archtitectures also protect the guest
OS from the hypervisor by providing secure enclaves (intel)/realms(arm).

The architectural features supporting virtualization are designed to
isolate guests from both the hypervisor and other guests.

Lawrence D'Oliveiro wrote:

> On Wed, 13 Mar 2024 23:18:37 +0000, MitchAlsup1 wrote:

>> Hypervisors are absolutely necessary if you want high RAS where a
>> GuestOS may crash without taking the system down.

> Not really. Remember, the whole point about introducing memory protection
> into multitasking, multiuser OSes in the first place was precisely so that
> one program could crash without taking the system down.

What happens to the non-HyperVised system when GuestOS goes down ??
{{Guest OS is a program, is it not ??}}

On 3/12/2024 5:02 PM, BGB wrote:
> On 3/12/2024 2:11 PM, Chris M. Thomasson wrote:
>> On 3/10/2024 4:30 PM, Chris M. Thomasson wrote:
>> [...]
>>> Something akin to my old alignment code:
>>>
>>> https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ
>> [...]
>>
>> To BGB / cr88192, your are the same person that replied to me in that
>> thread, right? Back in 2009?
>
> Looks like me, but off-hand I don't remember the contents of this
> thread, and this mostly predates my current projects...
>
> At the time, I would have been taking college classes, roughly mid 20s.
>
>
> IIRC, projects I was working on at that time:
>   A 3D engine (*);
>   A VM for a JavaScript/ActionScript inspired language;
>     Was being used as a scripting language for the 3D engine project.
>   ...
>
> At this time, it would have still been mostly a Doom 3 clone; as I
> didn't switch over to trying to imitate Minecraft until several years
> later.
>
>
> This was also sometime around the time I wrote the first version of
> BGBCC, based on a fork of the previous VM, modified to be able to parse
> C. However, initially, it wasn't very successful, and ended up mostly
> relegated to be a header-parser tool and FFI generator.
>
> I had used garbage collectors and similar more often back then, but have
> since largely ended up moving away from GC, as it is difficult to make
> it "not suck".
>
>
> I have been on usenet for a while...
>
>

Well done. Btw, do you happen to know anything about DirectX 12? I know
OpenGL, but I might need to move into DirectX land...

On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:

> The architectural features supporting virtualization are designed to
> isolate guests from both the hypervisor and other guests.

Providing an entire separate kernel for each VM is often unnecessary. If
you need separation at the level of entire subsystems, as opposed to
individual processes, then that’s what containers are for.

On Thu, 14 Mar 2024 00:27:38 +0000, MitchAlsup1 wrote:

> What happens to the non-HyperVised system when GuestOS goes down ??

Nothing. That’s what makes it a “guest”.

On 3/13/2024 8:32 PM, Chris M. Thomasson wrote:
> On 3/12/2024 5:02 PM, BGB wrote:
>> On 3/12/2024 2:11 PM, Chris M. Thomasson wrote:
>>> On 3/10/2024 4:30 PM, Chris M. Thomasson wrote:
>>> [...]
>>>> Something akin to my old alignment code:
>>>>
>>>> https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ
>>> [...]
>>>
>>> To BGB / cr88192, your are the same person that replied to me in that
>>> thread, right? Back in 2009?
>>
>> Looks like me, but off-hand I don't remember the contents of this
>> thread, and this mostly predates my current projects...
>>
>> At the time, I would have been taking college classes, roughly mid 20s.
>>
>>
>> IIRC, projects I was working on at that time:
>>    A 3D engine (*);
>>    A VM for a JavaScript/ActionScript inspired language;
>>      Was being used as a scripting language for the 3D engine project.
>>    ...
>>
>> At this time, it would have still been mostly a Doom 3 clone; as I
>> didn't switch over to trying to imitate Minecraft until several years
>> later.
>>
>>
>> This was also sometime around the time I wrote the first version of
>> BGBCC, based on a fork of the previous VM, modified to be able to
>> parse C. However, initially, it wasn't very successful, and ended up
>> mostly relegated to be a header-parser tool and FFI generator.
>>
>> I had used garbage collectors and similar more often back then, but
>> have since largely ended up moving away from GC, as it is difficult to
>> make it "not suck".
>>
>>
>> I have been on usenet for a while...
>>
>>
>
> Well done. Btw, do you happen to know anything about DirectX 12? I know
> OpenGL, but I might need to move into DirectX land...

I never really got into DirectX, and had always used OpenGL.

DirectX requires giving up on the ability to run code on non-Windows
targets. Meanwhile, OpenGL had generally kept options open (code written
for OpenGL in one context can be adapted to another context; but, if one
uses Direct3D, they are basically stuck with Windows...).

By the time Vulkan came around, I was already scaling back a lot on
graphics stuff, and it wasn't until a few months ago that I got a
graphics card actually capable of the whole RTX.

So, in terms of graphical features, ironically, my first 3D engine was
the fanciest. My later efforts were generally simpler, aiming more to
try to limit code complexity, improve performance, reduce resource
utilization, etc.

So, first BGBTech engine (BT1) ended up being around 1 MLOC, and tended
to use several GB of RAM. I had ended up using 64-bit builds, mostly
because otherwise it kept running out of 32-bit address space much past
around 1km^2 of chunks.

As can be noted, it was using a hybrid Doom 3 like rendering strategy.

For small/dynamic light-sources and entities, was using Depth-Pass
stencil shadowing (at the time, someone had patented the Depth Fail
stencil shadow strategy, forcing people to use of Depth Pass instead as
a workaround).

For the sun and world terrain, had used shadow maps (using stencil
shadows for the sun was not viable). General idea here is that one
renders to a depth texture from the perspective of the sun, pointing in
the general direction of the player. Then, when drawing the lighting for
the sun, the fragment shader could compare the position (in terms of
distance from the sun) with the texel in the depth-texture, to determine
whether this location is in line-of-sight of the sun.

I lost direction near the end of this project, as moving forward with
"gameplay" became less obvious, and so it mostly went out in a flurry of
me screwing around with using videos as texture-maps (seemed semi-novel
at the time). But, sticking random videos onto geometry does not make
for compelling gameplay (and in practice, I mostly just ended up using
it for animated textures; which is admittedly kind of overkill).

Second BGBTech engine (BT2) was around 150 kLOC. Was also able to get it
to run OK in a 256MB footprint, and on a RasPi and early 2000s laptop.
Had also done a WASM build, so it could run in a browser.

It had switched to a simpler design, namely just doing the lighting
using vertex colors (more like how Minecraft seemed to work). Shaders
ended up as optional and were not used as significantly (the engine
still worked acceptably with fixed-function rendering); and generally
the rendering could all be done in a single pass.

Initially, when designing things (in terms of graphics and other UI
aspects), had also taken some inspiration from Undertale and similar
(which was relatively popular in the mid/late 2010s).

This project mostly fizzled out, as I didn't have enough motivation to
work on both this and my BJX2 project, and personally I found my BJX2
project to be more interesting.

Third BGBTech engine (BT3) is around 30 kLOC and fits into around 60 MB
of RAM (though, one can add another 24 kLOC if one counts TKRA-GL in the
budget; but it can also work with native OpenGL). Where TKRA-GL in turn
exists because of a prior attempt of mine at implementing OpenGL in
software, which was (in part) because I had a laptop with a GPU that was
sufficiently bad as to make implementing the OpenGL API on top of a
software rasterizer seem like a valid option. Imagine a Vista era laptop
with a GPU (Intel GMA) weak enough that its claim to fame is that it can
give "mostly acceptable" framerates in Half-Life and Quake 3 Arena; or
one can just use Half-Life's software renderer, ... Well, along with
disabling Vista's Aero UI, mostly as it made everything unpleasantly
sluggish (well, nevermind if apparently the GPU didn't actually support
shaders in hardware; so all the transparency and blur stuff was
presumably being done in software), ...

The third engine mostly existed because the second engine was still too
heavyweight to be usable on the BJX2 core. Compared with its
predecessors (and actual Minecraft), its design is less well-suited to
larger draw distances (it scales poorly).

At present, BT3's codebase is smaller that my Doom engine port.

Partial contrast is ROTT, which was based on the Wolf3D engine, and
weighs in at around 130 kLOC. Though, ROTT is one of the larger programs
I am running on BJX2 at the moment. Quake3 is bigger (around 300 kLOC),
but I still haven't gotten around to finishing the Quake3 port (and I
don't expect it to be usable; even with a bunch of hacks to try to
reduce memory usage and similar).

In this case, both the BT1 and BT2 engines had worked by building
per-chunk vertex arrays. Then, for any potentially visible chunks, the
arrays were drawn.

In the BT3 engine, a different strategy was used:

From the point of view of the player, a bunch of rays are fired off in
every direction (in a roughly spherical pattern with randomized jitter
being added), and any block/face which a ray hits, is added to a list;
Then, for any block in the list, any visible faces are added into big
global vertex arrays, and then these vertex arrays are rendered.
Similarly, any blocks which haven't been hit recently enough end up
being removed from the list (along with blocks which are too far outside
the draw distance).

To some extent, this aspect of the engine was partly inspired by the
ROTT and Wolf3D engines, which use a ray-sweep to find any visible
walls, and also to build a list of visible sprites (say, if a ray passes
through a tile with sprite-entities in it, they are added to a list of
things to be drawn).

One possible strategy I considered (before my BT2 effort fizzled out)
was to try to allow larger draw-distances by rendering chunk faces to
textures, and then for distant chunks, rather than draw the chunk
geometry itself, one draws a cube with each face representing the chunk
as seen from that direction (in an orthographic sense).

Similar could also be possible for BT3, as a partial workaround for the
small draw-distances. Another possibility could be to use some
projection trickery, and then prerender a view from within each region
(a 128x128x128 meter cube in BT3) as its own cubemap. Cube faces could
then be rendered (with alpha blending) before rendering the visible blocks.

Otherwise, for BT3, had reused the texture atlas and similar from BT2.
Though, comparably much cruder (quick/dirty) sprite artwork (comparably,
for BT2, had used higher resolution sprites, and for BT1 had used 3D
models).

Partly the use of sprites in BT2 was for aesthetic reasons, and partly
also because it is a lot less effort to draw sprites than to 3D model
stuff (could have re-added 3D models if I wanted).

Had otherwise been tempted to try to take inspiration from Stardew
Valley, but gameplay in Stardew Valley is very different (it is mostly
focused on prescripted character interactions in an top-down 2D
environment; with farming-sim and dungeon-crawler aspects), and it is
not obvious how to integrate them (and the worlds are also built
manually rather than procedural generation).

On 3/13/2024 5:37 PM, Robert Finch wrote:
> On 2024-03-13 2:29 p.m., BGB wrote:
>> On 3/12/2024 10:31 PM, Robert Finch wrote:
>>> Can capabilities be applied to address ranges?
>>>
>>> Segmentation similar to the PowerPC 32-bit segmentation is being used
>>> in the current project. Where the upper address bits select a segment
>>> register which provides more address bits. I would like to use the
>>> same descriptors for capabilities and the address range segmentation.
>>>
>>
>> Something like a segmentation scheme could also work.
>>
>> Though, these seem like two different approaches, so there wouldn't be
>> as much value in a shared descriptor. Segmentation also tends to be
>> more coarse grained, rather than something applied to individual
>> memory objects.
>>
> Segmentation and capabilities look similar to me. They both have base /
> bounds and permissions / access rights. The difference is the capability
> carries along the pointer value and a segment descriptor does not. There
> is the object type too, more specific than just code or data.
>

A capability effectively encodes 3 addresses:
An upper bound, lower bound, and a target address.
A segment descriptor generally only needs two:
A base address, and a size.

Similarly, segmentation often uses some sort of descriptor table, rather
than large pointers. Though, some stuff I read implied that many
capability machines were effectively handle based, encoding a capability
as a combination of object handle and displacement. This is a different
model (vs, say, trying to cram everything into a 128-bit pointer-like
object).

>> Of these two, I am left to suspect that segmented addressing may
>> actually be the less painful of the two...
>>
>>
>>
>> But, yeah, I was looking into a possible "Bounds Check Enforced" mode:
>>    Will require using XMOV.x instructions to access memory;
>>    Will check and enforce the use of tag bits.
>>      The tag bits will be ignored in the normal mode.
>>
>> ISA level changes:
>> Will need a flag-bit, and a few more instructions for working with
>> pointers / capabilities;
>> Will require a Tag-RAM area in DRAM.
>
> One thought I had was to use whole bytes instead of just a tag bit. That
> would make tag "bits" accessible with regular load and store
> instructions. But also had considered using a second bit to indicate a
> pointer store for garbage collection. If using one bit, why not use two?
> One BRAM can handle a lot of tag bits.
>

Possibly, but as noted, at 1/128 the RAM, for a 128MB RAM module, one
needs 1MB of tag bits.

This is a bit more than one can reasonably keep entirely in Block-RAM,
so it will be needed to back it out to main RAM.

>>
>> If the enforced mode is not supported, probably setting this flag will
>> be No-Op, and the Tag-RAM will not be used.
>>
>>
>> Micro-arch changes:
>>    Registers are extended from 64 to 66 bits;
>>    Load/Store operations also have 2 extra bits;
>>      Will only apply to 128-bit MOV.X and XMOV.X ops.
>>    Most operations will just set these bits to 0.
>>
> What is the second extra bit for?
>

Probably to later represent invalid values or similar.

The memory interface will only store 1 bit per 128-bits, but registers
will have 2 bits per 64-bit register.

Partly this is to make it easier to verify if capabilities are still
intact, when generally each part travels along a different 64-bit path.

For now:
00: Data
01: Capability
10: Reserved / Not-a-Value
11: Reserved

>> Unlike in the normal memory protection, handling of capability
>> enforcement will be done in the EX-stage logic, rather than in the L1
>> cache.
>
> Hm, I was going to handle capabilities in the MEM stage logic.

In my case, the EX1/EX2/EX3 stages handle the pipeline facing parts of
the memory interface, whereas the L1 cache deals with the actual
load/store mechanism.

Bounds checking is handled in the AGU / AGEN logic, which is connected
to the EX1 stage logic. It makes sense to handle capability access
checks in the same area, since this logic can see the actual contents of
the registers (the L1 D$ merely sees the target address).

>>
>> Other effects:
>> ISR handling will now need to be more careful so as to not mess up the
>> tag bits for registers (specifics TBD);
>> The role of GBR/GP will need to be moved over into a GPR.
>>
>> May or may not consider making the register tag-bits accessible to
>> privileged code as CR's, but this is likely to have a higher cost. The
>> currently considered option is to have the ISR handler save the
>> registers with MOV.X instructions and then copy the corresponding
>> register tag bits out of Tag-RAM (and then restore these bits before
>> restoring the registers), but this will be fiddly.
>>
>>
>> Thus far:
>> Of the parts added thus far, seems to have a fairly small impact on
>> LUT budget.
>> As for whether or not this idea will be DOA, this is yet to be seen.
>> It requires effectively reviving the 128-bit ABI, which was also
>> another likely DOA feature.
>>
>> Only real incentive is for untrusted code, where security is more
>> important than performance (and one can live with a world where
>> integer->pointer casting is either not allowed or painfully slow, ...).
>
> In the document IIRC they said performance was an issue for capabilities
> in the past. Implying maybe that with the performance of a modern
> machine it may not be as painfully slow. Having an MMU was painfully
> slow too, adding a clock cycle onto all the memory access.

Slowness is subject to interpretation.

On modern PC's, many people consider writing non-trivial programs in
Python to be acceptable. But, compared to C, Python tends to be glacial.

Say, if a program is on-average 15-30% slower, this may be acceptable.
However, 5x slower would likely not be acceptable.

The main overheads of capabilities in my case being likely:
Memory overhead due to bigger pointers;
Likely to effect things like cache misses, etc.
Suddenly nearly everything takes twice as many registers;
So, it is like the register set got cut in half.
The memory ops now have smaller displacements:
MOV.x has Disp9u / Disp10s
XMOV.x has Disp5u / Disp6s
Integer to pointer casts will have a significant overhead;
The XMOV.x ops will be scalar only.
...

With the prior bounds-check support (in the 64-bit ABI), there was
around a 10% overhead, but this was with 64-bit pointers and mostly
still leveraging the existing ISA where possible.

I am guessing Bounds-Check-Enforce is more likely to have around a 30%
overhead, maybe more or less. But, this is likely also to be for code
that is potentially hostile. But, then, one wants the security to be
strong enough that there is no practical way for code to break out of
the sandbox; though, if allowing for arbitrary machine code, then there
is still the great potential Achilles heel that is the Global Pointer or
GOT. Only sure way to avoid this is to not have any "potentially
compromising" capabilities anywhere within the graph of what is
reachable from the hostile code, and the main obvious way to do this is
via the use of system call.

If operating solely at the C level, it is a little easier: One needs to
make sure that there is no way for the code to get direct access to the
Global Pointer or GOT or similar. An ABI based on FDPIC would be bad
here, since it is within the reach of C code (under typical C behavior,
UB notwithstanding) to be able to gain access to the GOT for an
arbitrary function pointer.

A big chunk of this would be overhead shared with the 128-bit ABI (which
would have gone over entirely to 128-bit bounds-checked pointers), with
a few new/additional overheads.

For things like network-stack code, it is more likely to be sufficient
to use the normal (non-enforced) bounds-checks.

As for whether it makes sense to support the relative expense of tagged
memory for a niche edge case, I don't know.

>>
>>
>> More likely, the use of optional bounds-checking with 64-bit pointers
>> will remain as the more practical option, with the MMU and ACL checks
>> serving as the primary security mechanisms.
>>
>> ...
>>
>

In other news:
The frustrating bug I had been hunting, seemingly turned out to not have
been a CPU core bug, rather:
BGBCC was apparently doing something invalid (likely manifesting
somewhere in "printf()");
Then, "printf()" was stomping registers in the caller;
Some debugging attempts were essentially moving the bug around.

Robert Finch <robfi680@gmail.com> wrote:
> I am wondering if the ‘R’ term in the CHERI concentrate expansion calc
> can be less than zero or if it is a modulo value. It is shown as
> B[13:11] – 1. I am assuming it can go negative and is not modulo.

I understand it is signed, so can go negative:

https://github.com/CTSRD-CHERI/sail-cheri-riscv/blob/6e3613a2c46fb809e526b55c5c72acb041194ab8/src/cheri_cap_common.sail#L276

> How “open” is CHERI ? Can CHERI based code be posted?

CHERI is as open as we can make it:

The architecture specification is published: https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf

We have an agreement with Arm that 'capability essential IP' (ie IP which is
fundamental to the architecture, rather than details of the implementation)
is public and they won't patent it.

The Morello architecture spec is published. How Arm do their implementation
is up to them.

The CHERI-RISC-V (and MIPS) architectures are published in the above.
architecture specification. The Sail formal models are open source:
https://github.com/CTSRD-CHERI/sail-cheri-riscv

We have an ongoing effort to standardised CHERI through the RISC-V
standardisation process.

CHERI software (compiler, toolchain, CheriBSD, application changes) and
RISC-V (and MIPS) hardware artifacts (implementation of CHERI cores in RTL)
are open source.

There's certainly no problems about posting CHERI code - to be encouraged!

Theo

BGB <cr88192@gmail.com> wrote:
> Presumably, in addition to the code, one needs some way for the code to
> be able to access its own ".data" and ".bss" sections when called.

AIUI you derive a capability from PCC (the PC capability) that gives you
access to your local 'captable', which then holds pointers to your other
objects. The captable can be read-only but the capabilities inside it can
be writable (ie pointers allow you to write to your globals etc).

> Some options:
> PC-relative:
> Unclear if valid in this case.
> GOT:
> Table of pointers to things, loaded somehow.
> One example here being the ELF FDPIC ABI.
> Reloading a Global Pointer via a lookup table accessed via itself.
> This is what my ABI uses...
>
> I couldn't seem to find any technical descriptions of the CHERI/Morello
> ABI. I had made a guess that it might work similar to FDPIC, as this
> could be implemented without needing to use raw addresses (and seemed
> like a "best fit").

This is a description of the linkage model for CHERI MIPS; I'm not aware of
anything having changed significantly for RISC-V or Morello, although exact
usage of registers etc will be different.

https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20190113-cheri-linkage.pdf

This also describes the OS-facing ABI on CheriBSD:
https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf

Theo

Theo Markettos wrote:

> BGB <cr88192@gmail.com> wrote:
>> Presumably, in addition to the code, one needs some way for the code to
>> be able to access its own ".data" and ".bss" sections when called.

> AIUI you derive a capability from PCC (the PC capability) that gives you
> access to your local 'captable', which then holds pointers to your other
> objects. The captable can be read-only but the capabilities inside it can
> be writable (ie pointers allow you to write to your globals etc).

>> Some options:
>> PC-relative:
>> Unclear if valid in this case.
>> GOT:
>> Table of pointers to things, loaded somehow.
>> One example here being the ELF FDPIC ABI.
>> Reloading a Global Pointer via a lookup table accessed via itself.
>> This is what my ABI uses...
>>
>> I couldn't seem to find any technical descriptions of the CHERI/Morello
>> ABI. I had made a guess that it might work similar to FDPIC, as this
>> could be implemented without needing to use raw addresses (and seemed
>> like a "best fit").

> This is a description of the linkage model for CHERI MIPS; I'm not aware of
> anything having changed significantly for RISC-V or Morello, although exact
> usage of registers etc will be different.

> https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20190113-cheri-linkage.pdf

> This also describes the OS-facing ABI on CheriBSD:
> https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf

So, how does a Cheri machine do::

void foo( int * i )
{ static int j;
int *k = &j;

bar( k, i );
}

And how does a Cheri machine implement fprintf( file *f, ... ) from

void printf( ... )
{ fprintf( stdout, ... );
}

> Theo

On 3/14/2024 7:37 AM, Theo Markettos wrote:
> BGB <cr88192@gmail.com> wrote:
>> Presumably, in addition to the code, one needs some way for the code to
>> be able to access its own ".data" and ".bss" sections when called.
>
> AIUI you derive a capability from PCC (the PC capability) that gives you
> access to your local 'captable', which then holds pointers to your other
> objects. The captable can be read-only but the capabilities inside it can
> be writable (ie pointers allow you to write to your globals etc).
>
>> Some options:
>> PC-relative:
>> Unclear if valid in this case.
>> GOT:
>> Table of pointers to things, loaded somehow.
>> One example here being the ELF FDPIC ABI.
>> Reloading a Global Pointer via a lookup table accessed via itself.
>> This is what my ABI uses...
>>
>> I couldn't seem to find any technical descriptions of the CHERI/Morello
>> ABI. I had made a guess that it might work similar to FDPIC, as this
>> could be implemented without needing to use raw addresses (and seemed
>> like a "best fit").
>
> This is a description of the linkage model for CHERI MIPS; I'm not aware of
> anything having changed significantly for RISC-V or Morello, although exact
> usage of registers etc will be different.
>
> https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20190113-cheri-linkage.pdf
>
> This also describes the OS-facing ABI on CheriBSD:
> https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf
>

OK, cool.

I think I get it now:
You are using PC-rel within functions to load a capability to gain
access to global variables.

This is admittedly a different approach than what I had guessed.

I guess this works (and is secure) so long as only the callee can load
capabilities from within the region specified by the function-pointer
capability, but the caller can not load capabilities from it.

Though, admittedly, this would be less directly applicable to my own
system, where code and data sections are managed separately from each
other (one shared copy of the .text section may have multiple task
instances each with their own copies of the .data/.bss sections).

So, at least, in my case there would still be a potential weakness in
being able to walk the global pointer. Seems I will need to think up a
workaround.

Though, I guess one possibility could be to support a special-case
instruction for GBR reloads.

In my ISA, with my existing ABI, it looks something like:
MOV.Q (GBR, 0), R18
MOV #Index, R0 //*
MOV.Q (R18, R0), R18
MOV R18, GBR
(*: There are more efficient ways to load an index, but this is what I
had specified in the ABI. Could eliminate this constant load if the ABI
allows using a jumbo-prefix here. )

In the 128-bit secure ABI, possibly something like:
XMOV.X (R40, 0), R18
MOV #Index, R0
XMOV.X (R18, R0), R40
(Say, with R40 taking over the role of the Global Pointer from GBR).

But, might be better, say, to repurpose GBR itself as the Global Pointer
table:
MOV.X (GBR, Disp33), R40 //*
( *: Here, will assume that any implementation capable of this mode,
will also be able to support Jumbo prefixes... )

With (PC, Disp) and (GBR, Disp) loads being allowed, but most other use
of the normal MOV.x instructions being disallowed. Similarly, GBR could
become a read-only register in this mode.

If the programs can be disallowed from crafting their own machine-code,
then it becomes possible to check these instructions at load-time.
Though, the global-pointer weakness would re-appear if the program is
allowed to JIT compile stuff.

Though, this risk could be reduced by assigning the indices with random
numbers (so, the program has no way of knowing which entry in the table
belongs to which library, or which are valid and which are traps).

Well, at least, assuming the caller can't perform loads through function
pointers, and then proceed to mine the offset from the function's prolog
sequence.

I guess, this isn't perfect, but this would at least avoid needing to
invent new mechanisms in the ISA.

....

> Theo

On Thu, 14 Mar 2024 03:20:57 -0500, BGB wrote:

> A capability effectively encodes 3 addresses:
> An upper bound, lower bound, and a target address.
> A segment descriptor generally only needs two:
> A base address, and a size.

You need information on where the segment is located though, don’t you.

On 3/13/2024 10:32 PM, BGB wrote:
[...]
> Like, there isn't that huge of a gap between the technologies I had used
> in my 3D engines, and those I am using in BJX2 and TestKern. Many
> similar sorts of technologies end up being needed in both cases (say,
> for example, hierarchical filesystems capable of dealing with mount
> points, ...).

Sounds good, BGB. BTW, do you mind if I pick your brain on some of this
from time to time? I might even make a new thread so we can do it in
public. Or on email. My address is working. Fwiw, here is some of my
older modern opengl work:

https://youtu.be/n13GHyYEfLA

I made the music in one of my older MIDI programs. ;^D

BGB wrote:

> I am guessing Bounds-Check-Enforce is more likely to have around a 30%

My guess would be SQRT(30%) ~= 15%

> overhead, maybe more or less. But, this is likely also to be for code
> that is potentially hostile. But, then, one wants the security to be
> strong enough that there is no practical way for code to break out of
> the sandbox; though, if allowing for arbitrary machine code, then there
> is still the great potential Achilles heel that is the Global Pointer or
> GOT.

Note:: GOT is not ST-able in My 66000 architecture.....You can LD it into
a Register for accessing what it points at or you can LD it into IP and
execute code over there. {No trampoline}

> Only sure way to avoid this is to not have any "potentially
> compromising" capabilities anywhere

"within the graph of what is reachable from the hostile code" is redundant.
> and the main obvious way to do this is
> via the use of system call.

> If operating solely at the C level, it is a little easier: One needs to
> make sure that there is no way for the code to get direct access to the
> Global Pointer or GOT or similar. An ABI based on FDPIC would be bad
> here, since it is within the reach of C code (under typical C behavior,
> UB notwithstanding) to be able to gain access to the GOT for an
> arbitrary function pointer.

Application cannot ST to its GOT.

> A big chunk of this would be overhead shared with the 128-bit ABI (which
> would have gone over entirely to 128-bit bounds-checked pointers), with
> a few new/additional overheads.

Lawrence D'Oliveiro wrote:

> On Thu, 14 Mar 2024 00:27:38 +0000, MitchAlsup1 wrote:

>> What happens to the non-HyperVised system when GuestOS goes down ??

> Nothing. That’s what makes it a “guest”.

Ok, you are running RealOS and RealOS crashes/hangs/"does not fetch and execute
instructions"--you say nothing happens--I guess you are correct in your wording
but this is far from what anyone anticipates.

There is no-one to take over.......and deal with the GuestOS crash.......

Lawrence D'Oliveiro wrote:

> On Thu, 14 Mar 2024 00:11:55 GMT, Scott Lurndal wrote:

>> The architectural features supporting virtualization are designed to
>> isolate guests from both the hypervisor and other guests.

> Providing an entire separate kernel for each VM is often unnecessary. If
> you need separation at the level of entire subsystems, as opposed to
> individual processes, then that’s what containers are for.

If you are running k Linuxes under a single HyperVisor, you should be able
to share all the Linux code after giving each of them their own VaS for data.

Similarly, all library code used by the kernel should be shared uniformly
across all users, too {{stdlib, libm, strlib, ...}} where each chunk of
code gets its own static (and global) variables in scope.

On 3/14/2024 3:11 PM, MitchAlsup1 wrote:
> Lawrence D'Oliveiro wrote:
>
>> On Thu, 14 Mar 2024 00:27:38 +0000, MitchAlsup1 wrote:
>
>>> What happens to the non-HyperVised system when GuestOS goes down ??
>
>> Nothing. That’s what makes it a “guest”.
>
>
> Ok, you are running RealOS and RealOS crashes/hangs/"does not fetch and
> execute
> instructions"--you say nothing happens--I guess you are correct in your
> wording but this is far from what anyone anticipates.
>
> There is no-one to take over.......and deal with the GuestOS crash.......

GuestOS in a sandbox?

On 3/14/2024 3:18 PM, Chris M. Thomasson wrote:
> On 3/14/2024 3:11 PM, MitchAlsup1 wrote:
>> Lawrence D'Oliveiro wrote:
>>
>>> On Thu, 14 Mar 2024 00:27:38 +0000, MitchAlsup1 wrote:
>>
>>>> What happens to the non-HyperVised system when GuestOS goes down ??
>>
>>> Nothing. That’s what makes it a “guest”.
>>
>>
>> Ok, you are running RealOS and RealOS crashes/hangs/"does not fetch
>> and execute
>> instructions"--you say nothing happens--I guess you are correct in
>> your wording but this is far from what anyone anticipates.
>>
>> There is no-one to take over.......and deal with the GuestOS crash.......
>
> GuestOS in a sandbox?

This reminds me of robust mutexes, for some reason... Ala POSIX...

Lawrence D'Oliveiro wrote:

> On Wed, 13 Mar 2024 23:18:37 +0000, MitchAlsup1 wrote:

>> Hypervisors are absolutely necessary if you want high RAS where a
>> GuestOS may crash without taking the system down.

> Not really. Remember, the whole point about introducing memory protection
> into multitasking, multiuser OSes in the first place was precisely so that
> one program could crash without taking the system down.

Exactly the same reason HyperVisors were introduced, so GuestOSs could crash
without taking down the system. A GuestOS crash does take down the applications
it happens to be running at the instant of crashing.

On Thu, 14 Mar 2024 22:11:41 +0000, MitchAlsup1 wrote:

> There is no-one to take over.......and deal with the GuestOS
> crash.......

You can have a management process in the host that watches for these sorts
of events, easily enough.