Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
Morello architecture, which is effectively a modified Aarch64, except:
Expands GPRs to 129 bits (internally);
Integer ISA remains 64-bit;
Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
addresses (the rest of the bits are used as protection flags and bounds
checks);
In effect, all pointers expand to 128 bits in memory;
Code isn't allowed to craft its own pointers (directly) because doing so
would break its memory protection scheme (the 129th bit is stored
separately, seemingly to track which memory locations contain pointers,
and to disallow loading a pointer from memory which has been used for data);
....

From the original thread:
https://www.theregister.com/2022/01/21/arm_morello_testing/
https://www.arm.com/architecture/cpu/morello
https://developer.arm.com/documentation/ddi0606/latest
Also found:
https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst

In effect, it seems like the program can't be allowed to craft or modify
its own pointers directly, as code doing so would break its whole memory
protection scheme. In effect, pointers would need to be derived from
other pointers.

I guess it works, but I am slightly skeptical of this idea:
Making all the pointers twice the size is not ideal for memory footprint;
This would have a potentially significant impact on existing codebases:
They can no longer assume sizeof(long)==sizeof(void *);
Code can no longer bit-twiddle their pointers;
...

While there are ways one would allow for 64-bit pointers, there isn't a
good way to do so without (also) blowing a massive hole in the whole
security scheme.

It effectively means that any code which relies on NaN tagging, tagged
pointers, or other sorts of pointer hackery, would need to rewritten to
work on such an architecture.

I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
approach, since this need not have any visible impact on how C operates
(pointers can remain 64 bits, code is free to bit-twiddle its pointers,
....).

Some properties of capabilities could be emulated (albeit imperfectly)
by using more conventional ASLR strategies (would be more effective in
an expanded 96-bit address space, as this could make it computationally
infeasible to "guess" the addresses to things).

Though, admittedly, if I were designing it now, I would likely have
skipped over the UID/GID part of VUGID and gone for using ACL checks
exclusively (the ACL check mechanism is more "general purpose" and also
takes up fewer bits in the TLB and page-table entries due to not needing
to store the access-mode bits directly in the TLBE/PTE).

In other cases, the protections from "true" capabilities become
unnecessary, since an MMU ACL check does not need to care how one
arrived at an address, merely whether or not the executing code is
allowed to access it (also cheaper to implement as well, at least with
the ACL miss logic offloaded to an ISR).

One can also gain implicit bounds checking via the huge expanses of
"nothingness" which would surround most larger memory allocations.

Within 96-bit land, it could make sense to enforce a minimum distance of
32GB between mmaps, as this would in effect make it "technically
impossible" for an out-of-bounds access on one object to collide with
any other object.

The "big expanse of nothingness" approach would not offer protection for
normal heap objects or stack allocations, but capabilities will not
offer this either unless there are instructions to compose a smaller
bounds-checked capability from a bigger one (would require more looking
into).

In my case, there were separate (software enforced) schemes for
bounds-checked arrays (as part of the pointer type-tagging scheme):
0xxx: Pointer, xxx=TypeTag
2xxx: Bounded Array, xxx=size (0..4095)
Cxxx: Displaced Array, xxx=Offset (0..4095)

Similar could be done with XMOV pointers, just with the bounds-check
expanded to 28 bits:
(127:112): Bounds(27:12)
(111: 64): Address(95:48)
( 63: 60): Tag (0010)
( 59: 48): Bounds(11:0)
( 47: 0): Address(47:0)

It is possible that, if it really mattered, a case for XMOV instructions
with integrated bounds-checking could be added (to avoid needing to
spend a few extra clock cycles on external bounds checks).

Using out-of-band tag bits to make registers and memory "tamper
resistant" is an interesting idea. There are a few places where this
could be useful.

Main issue is how to do this cost-effectively.
Option 1: Another specialized L1 cache (undesirable);
Option 2: Make cache lines several bits larger.
L2 now needs to deal with it, somehow...

Most ideas I can think of would either require another specialized
cache, or effectively result in non-power-of-2 memory addressing, or both.

Any thoughts?...

On Thursday, January 27, 2022 at 4:48:18 PM UTC-6, BGB wrote:
> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
> Morello architecture, which is effectively a modified Aarch64, except:
> Expands GPRs to 129 bits (internally);
> Integer ISA remains 64-bit;
> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> addresses (the rest of the bits are used as protection flags and bounds
> checks);
> In effect, all pointers expand to 128 bits in memory;
> Code isn't allowed to craft its own pointers (directly) because doing so
> would break its memory protection scheme (the 129th bit is stored
> separately, seemingly to track which memory locations contain pointers,
> and to disallow loading a pointer from memory which has been used for data);
> ...
>
> From the original thread:
> https://www.theregister.com/2022/01/21/arm_morello_testing/
> https://www.arm.com/architecture/cpu/morello
> https://developer.arm.com/documentation/ddi0606/latest
> Also found:
>
> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>
>
> In effect, it seems like the program can't be allowed to craft or modify
> its own pointers directly, as code doing so would break its whole memory
> protection scheme. In effect, pointers would need to be derived from
> other pointers.
>
I am sitting around wondering whether there is an exploit based on having
the OS as the upper (negative) part of the users address space. My guess
is that there is......so, unless they rewrite Linux this is not much more than
an experiment to see if anyone will "buy" this.
>
> I guess it works, but I am slightly skeptical of this idea:
> Making all the pointers twice the size is not ideal for memory footprint;
> This would have a potentially significant impact on existing codebases:
> They can no longer assume sizeof(long)==sizeof(void *);
> Code can no longer bit-twiddle their pointers;
<
Which might be a GOOD thing, but I digress.
<
> ...
>
> While there are ways one would allow for 64-bit pointers, there isn't a
> good way to do so without (also) blowing a massive hole in the whole
> security scheme.
<
<
I do not see how to create an array/matrix that consumes 60+ bits of address
space.
>
> It effectively means that any code which relies on NaN tagging, tagged
> pointers, or other sorts of pointer hackery, would need to rewritten to
> work on such an architecture.
>
No pity from me, here.
>
>
> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
> approach, since this need not have any visible impact on how C operates
> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
> ...).
>
> Some properties of capabilities could be emulated (albeit imperfectly)
> by using more conventional ASLR strategies (would be more effective in
> an expanded 96-bit address space, as this could make it computationally
> infeasible to "guess" the addresses to things).
<
My guess is that RoP attacks will still be feasible, don't see how this
alters MeltDown or Spectré like attacks.
>
> Though, admittedly, if I were designing it now, I would likely have
> skipped over the UID/GID part of VUGID and gone for using ACL checks
> exclusively (the ACL check mechanism is more "general purpose" and also
> takes up fewer bits in the TLB and page-table entries due to not needing
> to store the access-mode bits directly in the TLBE/PTE).
>
>
> In other cases, the protections from "true" capabilities become
> unnecessary, since an MMU ACL check does not need to care how one
> arrived at an address, merely whether or not the executing code is
> allowed to access it (also cheaper to implement as well, at least with
> the ACL miss logic offloaded to an ISR).
>
>
> One can also gain implicit bounds checking via the huge expanses of
> "nothingness" which would surround most larger memory allocations.
>
> Within 96-bit land, it could make sense to enforce a minimum distance of
> 32GB between mmaps, as this would in effect make it "technically
> impossible" for an out-of-bounds access on one object to collide with
> any other object.
>
>
> The "big expanse of nothingness" approach would not offer protection for
> normal heap objects or stack allocations, but capabilities will not
> offer this either unless there are instructions to compose a smaller
> bounds-checked capability from a bigger one (would require more looking
> into).
>
>
> In my case, there were separate (software enforced) schemes for
> bounds-checked arrays (as part of the pointer type-tagging scheme):
> 0xxx: Pointer, xxx=TypeTag
> 2xxx: Bounded Array, xxx=size (0..4095)
> Cxxx: Displaced Array, xxx=Offset (0..4095)
>
>
> Similar could be done with XMOV pointers, just with the bounds-check
> expanded to 28 bits:
> (127:112): Bounds(27:12)
> (111: 64): Address(95:48)
> ( 63: 60): Tag (0010)
> ( 59: 48): Bounds(11:0)
> ( 47: 0): Address(47:0)
>
> It is possible that, if it really mattered, a case for XMOV instructions
> with integrated bounds-checking could be added (to avoid needing to
> spend a few extra clock cycles on external bounds checks).
>
>
>
> Using out-of-band tag bits to make registers and memory "tamper
> resistant" is an interesting idea. There are a few places where this
> could be useful.
>
> Main issue is how to do this cost-effectively.
> Option 1: Another specialized L1 cache (undesirable);
> Option 2: Make cache lines several bits larger.
> L2 now needs to deal with it, somehow...
>
> Most ideas I can think of would either require another specialized
> cache, or effectively result in non-power-of-2 memory addressing, or both..
>
>
> Any thoughts?...
<
Will go don in the history books as another attempt at capabilities.

> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM Morello
> architecture, which is effectively a modified Aarch64, except:
> Expands GPRs to 129 bits (internally);
> Integer ISA remains 64-bit;
> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> addresses (the rest of the bits are used as protection flags and bounds
> checks);
> In effect, all pointers expand to 128 bits in memory;
> Code isn't allowed to craft its own pointers (directly) because doing so
> would break its memory protection scheme (the 129th bit is stored
> separately, seemingly to track which memory locations contain pointers, and
> to disallow loading a pointer from memory which has been used for data);

AFAIK the main issue with such things is what they do about dangling
pointers, i.e. dangling capabilities. Do they rely on a GC that's part
of the "trusted runtime"? or do they disallow deallocation altogether?
or do they rely on address-space randomization to make such dangling
capabilities "harmless" (they'll hopefully only make you crash but are
harder to exploit)?

The designs that keep the actual capabilities in a kind of
separate/secured table (so the untrusted code only handles references to
these capabilities and can thus do anything it wants within its sandbox
without needing any special XX=1bit values) have a much easier time
since they can much more easily ensure the absence of
references/capabilities before deallocating resources, or they can mark
them as dead).

Stefan

On 1/27/2022 2:48 PM, BGB wrote:
> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
> Morello architecture, which is effectively a modified Aarch64, except:
> Expands GPRs to 129 bits (internally);
> Integer ISA remains 64-bit;
> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> addresses (the rest of the bits are used as protection flags and bounds
> checks);
> In effect, all pointers expand to 128 bits in memory;
> Code isn't allowed to craft its own pointers (directly) because doing so
> would break its memory protection scheme (the 129th bit is stored
> separately, seemingly to track which memory locations contain pointers,
> and to disallow loading a pointer from memory which has been used for
> data);
> ...
>
> From the original thread:
>   https://www.theregister.com/2022/01/21/arm_morello_testing/
>   https://www.arm.com/architecture/cpu/morello
>   https://developer.arm.com/documentation/ddi0606/latest
> Also found:
>
> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>
>
>
> In effect, it seems like the program can't be allowed to craft or modify
> its own pointers directly, as code doing so would break its whole memory
> protection scheme. In effect, pointers would need to be derived from
> other pointers.
>
>
> I guess it works, but I am slightly skeptical of this idea:
> Making all the pointers twice the size is not ideal for memory footprint;
> This would have a potentially significant impact on existing codebases:
>   They can no longer assume sizeof(long)==sizeof(void *);
>   Code can no longer bit-twiddle their pointers;
>   ...
>
> While there are ways one would allow for 64-bit pointers, there isn't a
> good way to do so without (also) blowing a massive hole in the whole
> security scheme.
>
> It effectively means that any code which relies on NaN tagging, tagged
> pointers, or other sorts of pointer hackery, would need to rewritten to
> work on such an architecture.
>
>
>
> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
> approach, since this need not have any visible impact on how C operates
> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
> ...).
>
> Some properties of capabilities could be emulated (albeit imperfectly)
> by using more conventional ASLR strategies (would be more effective in
> an expanded 96-bit address space, as this could make it computationally
> infeasible to "guess" the addresses to things).
>
> Though, admittedly, if I were designing it now, I would likely have
> skipped over the UID/GID part of VUGID and gone for using ACL checks
> exclusively (the ACL check mechanism is more "general purpose" and also
> takes up fewer bits in the TLB and page-table entries due to not needing
> to store the access-mode bits directly in the TLBE/PTE).
>
>
> In other cases, the protections from "true" capabilities become
> unnecessary, since an MMU ACL check does not need to care how one
> arrived at an address, merely whether or not the executing code is
> allowed to access it (also cheaper to implement as well, at least with
> the ACL miss logic offloaded to an ISR).
>
>
> One can also gain implicit bounds checking via the huge expanses of
> "nothingness" which would surround most larger memory allocations.
>
> Within 96-bit land, it could make sense to enforce a minimum distance of
> 32GB between mmaps, as this would in effect make it "technically
> impossible" for an out-of-bounds access on one object to collide with
> any other object.
>
>
> The "big expanse of nothingness" approach would not offer protection for
> normal heap objects or stack allocations, but capabilities will not
> offer this either unless there are instructions to compose a smaller
> bounds-checked capability from a bigger one (would require more looking
> into).
>
>
> In my case, there were separate (software enforced) schemes for
> bounds-checked arrays (as part of the pointer type-tagging scheme):
>   0xxx: Pointer, xxx=TypeTag
>   2xxx: Bounded Array, xxx=size (0..4095)
>   Cxxx: Displaced Array, xxx=Offset (0..4095)
>
>
> Similar could be done with XMOV pointers, just with the bounds-check
> expanded to 28 bits:
>   (127:112): Bounds(27:12)
>   (111: 64): Address(95:48)
>   ( 63: 60): Tag (0010)
>   ( 59: 48): Bounds(11:0)
>   ( 47:  0): Address(47:0)
>
> It is possible that, if it really mattered, a case for XMOV instructions
> with integrated bounds-checking could be added (to avoid needing to
> spend a few extra clock cycles on external bounds checks).
>
>
>
> Using out-of-band tag bits to make registers and memory "tamper
> resistant" is an interesting idea. There are a few places where this
> could be useful.
>
> Main issue is how to do this cost-effectively.
>   Option 1: Another specialized L1 cache (undesirable);
>   Option 2: Make cache lines several bits larger.
>     L2 now needs to deal with it, somehow...
>
> Most ideas I can think of would either require another specialized
> cache, or effectively result in non-power-of-2 memory addressing, or both.
>
>
> Any thoughts?...

Many thoughts.

I'm a great fan of caps systems; I wish Mill could have been a caps
architecture.

The problem is that a move to 128 bit pointers breaks existing codes
that assume what the pointer size is, due to externally defined
interfaces such as data layouts. The market was willing to tolerate such
breaks in the moves 16->32->64 bit addresses because the older, smaller
sizes became hopelessly unusable. But move to 126? No - people will say
"My code runs fine with 64-bit pointers. These caps thingummies claim to
offer a bunch of new benefits, but I don't yet have to have them, so
I'll look into it - someday."

A secondary issue is that there's an enormous mass of unstructured
monolithic code out there, that would need majorly redesign to use caps
for anything more than bounds checking. Bounds checking is the least of
the gain from caps.But the legacy data format issue is why we went with
a grant system. It helps that we can do bounds checking without needing
expanded data.

On 1/27/2022 3:40 PM, MitchAlsup wrote:
> On Thursday, January 27, 2022 at 4:48:18 PM UTC-6, BGB wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
>> Morello architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and bounds
>> checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing so
>> would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain pointers,
>> and to disallow loading a pointer from memory which has been used for data);
>> ...
>>
>> From the original thread:
>> https://www.theregister.com/2022/01/21/arm_morello_testing/
>> https://www.arm.com/architecture/cpu/morello
>> https://developer.arm.com/documentation/ddi0606/latest
>> Also found:
>>
>> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>>
>>
>> In effect, it seems like the program can't be allowed to craft or modify
>> its own pointers directly, as code doing so would break its whole memory
>> protection scheme. In effect, pointers would need to be derived from
>> other pointers.
>>
> I am sitting around wondering whether there is an exploit based on having
> the OS as the upper (negative) part of the users address space. My guess
> is that there is......so, unless they rewrite Linux this is not much more than
> an experiment to see if anyone will "buy" this.
>>
>> I guess it works, but I am slightly skeptical of this idea:
>> Making all the pointers twice the size is not ideal for memory footprint;
>> This would have a potentially significant impact on existing codebases:
>> They can no longer assume sizeof(long)==sizeof(void *);
>> Code can no longer bit-twiddle their pointers;
> <
> Which might be a GOOD thing, but I digress.
> <
>> ...
>>
>> While there are ways one would allow for 64-bit pointers, there isn't a
>> good way to do so without (also) blowing a massive hole in the whole
>> security scheme.
> <
> <
> I do not see how to create an array/matrix that consumes 60+ bits of address
> space.
>>
>> It effectively means that any code which relies on NaN tagging, tagged
>> pointers, or other sorts of pointer hackery, would need to rewritten to
>> work on such an architecture.
>>
> No pity from me, here.
>>
>>
>> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
>> approach, since this need not have any visible impact on how C operates
>> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
>> ...).
>>
>> Some properties of capabilities could be emulated (albeit imperfectly)
>> by using more conventional ASLR strategies (would be more effective in
>> an expanded 96-bit address space, as this could make it computationally
>> infeasible to "guess" the addresses to things).
> <
> My guess is that RoP attacks will still be feasible, don't see how this
> alters MeltDown or Spectré like attacks.

ROP can be blocked because the return address is a cap and can't be
diddled. Meltdown and Spectre don't depend on addressing and so are
unhindered.

On 1/27/2022 4:23 PM, Stefan Monnier wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM Morello
>> architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and bounds
>> checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing so
>> would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain pointers, and
>> to disallow loading a pointer from memory which has been used for data);
>
> AFAIK the main issue with such things is what they do about dangling
> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
> of the "trusted runtime"? or do they disallow deallocation altogether?
> or do they rely on address-space randomization to make such dangling
> capabilities "harmless" (they'll hopefully only make you crash but are
> harder to exploit)?
>
> The designs that keep the actual capabilities in a kind of
> separate/secured table (so the untrusted code only handles references to
> these capabilities and can thus do anything it wants within its sandbox
> without needing any special XX=1bit values) have a much easier time
> since they can much more easily ensure the absence of
> references/capabilities before deallocating resources, or they can mark
> them as dead).
>
>
> Stefan

Isn't it Terje who says anything can be done with another layer of
indirection?

Revoke of permissions (and scavenge of permitted resources) is a very
hard problem in any permission system, including caps - and paging
tables too for that matter. These days narrow-cast caps (a.k.a handles)
typically use usecount GC. Which in practice works OK for well-behaved
users, Let a DOS attacker on your system though...

On 1/27/2022 5:40 PM, MitchAlsup wrote:
> On Thursday, January 27, 2022 at 4:48:18 PM UTC-6, BGB wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
>> Morello architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and bounds
>> checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing so
>> would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain pointers,
>> and to disallow loading a pointer from memory which has been used for data);
>> ...
>>
>> From the original thread:
>> https://www.theregister.com/2022/01/21/arm_morello_testing/
>> https://www.arm.com/architecture/cpu/morello
>> https://developer.arm.com/documentation/ddi0606/latest
>> Also found:
>>
>> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>>
>>
>> In effect, it seems like the program can't be allowed to craft or modify
>> its own pointers directly, as code doing so would break its whole memory
>> protection scheme. In effect, pointers would need to be derived from
>> other pointers.
>>
> I am sitting around wondering whether there is an exploit based on having
> the OS as the upper (negative) part of the users address space. My guess
> is that there is......so, unless they rewrite Linux this is not much more than
> an experiment to see if anyone will "buy" this.

Unless there are fairly significant modifications to a lot of existing
code, it is quite possible that this would be dead on arrival.

Like, even if it is still (more or less) the same basic Aarch64 ISA at
its core, needing an extensive porting effort to make the existing
software ecosystem work on it is likely to be a deal-breaker for general
adoption.

This isn't exactly an "everything will work as-is" or even a "recompile
and it's all good" level of a change.

>>
>> I guess it works, but I am slightly skeptical of this idea:
>> Making all the pointers twice the size is not ideal for memory footprint;
>> This would have a potentially significant impact on existing codebases:
>> They can no longer assume sizeof(long)==sizeof(void *);
>> Code can no longer bit-twiddle their pointers;
> <
> Which might be a GOOD thing, but I digress.
> <

This would, however, break a lot of real world code.

>> ...
>>
>> While there are ways one would allow for 64-bit pointers, there isn't a
>> good way to do so without (also) blowing a massive hole in the whole
>> security scheme.
> <
> <
> I do not see how to create an array/matrix that consumes 60+ bits of address
> space.

Yeah, apparently this would not be possible on either Morello, or
"natively" on BJX2.

Morello:
The capability encodings will not allow for it.

BJX2:
Will not fit within a 48 bit quadrant;
Nor within a 33 bit displacement;
But, could be emulated via ALU ops...

__lea_mega_b: //X4=Base, R6=Disp
MOV 0x0000FFFFFFFFFFFF, R16
MOV 0xFFFF000000000000, R17
AND R4, R16, R18 | AND R4, R17, R2
MOV R5, R3 | ADD R18, R6, R18
AND R18, R16, R20 | SHAD.Q R18, -48, R21
OR R20, R2 | ADD R21, R3
RTS

Not ideal, but probably works (could emulate a full 64-bit displacement
within the 96 bit addressing scheme).

Currently most things assume either an 'int' or 'unsigned int' displacement.

>>
>> It effectively means that any code which relies on NaN tagging, tagged
>> pointers, or other sorts of pointer hackery, would need to rewritten to
>> work on such an architecture.
>>
> No pity from me, here.

Things like NaN tagging and similar are not exactly uncommon.

>>
>>
>> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
>> approach, since this need not have any visible impact on how C operates
>> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
>> ...).
>>
>> Some properties of capabilities could be emulated (albeit imperfectly)
>> by using more conventional ASLR strategies (would be more effective in
>> an expanded 96-bit address space, as this could make it computationally
>> infeasible to "guess" the addresses to things).
> <
> My guess is that RoP attacks will still be feasible, don't see how this
> alters MeltDown or Spectré like attacks.

Yeah, dunno...

Some amount of temporal randomization might also be needed.

Things like stack canaries can at least help protect the return address
from tampering due to buffer overruns or similar.

One other partial protection (now enabled again in my compiler) is that
the layout of code within binaries is randomized on every rebuild. So,
the binary can be loaded both to a randomized address and also with
every function and variable shuffled into a random order. Should be
pretty hard to exploit at least assuming the program is recompiled
periodically.

ALSR works OK so long as the RNG is sufficiently unpredictable, which in
turn depends on the availability of a decent entropy source.

A few examples:
Detecting "noise" via a microphone or antenna;
Metastable clocks;
The low order bits of a thermometer;
Entropy from an external source, such as the timing and checksums of
encountered network packets (on a network-connected device);
....

Then, say, the CPU sits around mining entropy and running an internal
random number generator, where code can fetch random numbers on request
(such as via CPUID or similar), or periodically reseeding some random
numbers used internally within the core.

Though, granted, some of this is still a little theoretical in my case,
since ASLR depends some on having programs running from virtual memory,
where virtual memory is still pretty experimental and thus far I haven't
been running programs from virtual memory addresses. May need to get
back to working on this part.

>>
>> Though, admittedly, if I were designing it now, I would likely have
>> skipped over the UID/GID part of VUGID and gone for using ACL checks
>> exclusively (the ACL check mechanism is more "general purpose" and also
>> takes up fewer bits in the TLB and page-table entries due to not needing
>> to store the access-mode bits directly in the TLBE/PTE).
>>
>>
>> In other cases, the protections from "true" capabilities become
>> unnecessary, since an MMU ACL check does not need to care how one
>> arrived at an address, merely whether or not the executing code is
>> allowed to access it (also cheaper to implement as well, at least with
>> the ACL miss logic offloaded to an ISR).
>>
>>
>> One can also gain implicit bounds checking via the huge expanses of
>> "nothingness" which would surround most larger memory allocations.
>>
>> Within 96-bit land, it could make sense to enforce a minimum distance of
>> 32GB between mmaps, as this would in effect make it "technically
>> impossible" for an out-of-bounds access on one object to collide with
>> any other object.
>>
>>
>> The "big expanse of nothingness" approach would not offer protection for
>> normal heap objects or stack allocations, but capabilities will not
>> offer this either unless there are instructions to compose a smaller
>> bounds-checked capability from a bigger one (would require more looking
>> into).
>>
>>
>> In my case, there were separate (software enforced) schemes for
>> bounds-checked arrays (as part of the pointer type-tagging scheme):
>> 0xxx: Pointer, xxx=TypeTag
>> 2xxx: Bounded Array, xxx=size (0..4095)
>> Cxxx: Displaced Array, xxx=Offset (0..4095)
>>
>>
>> Similar could be done with XMOV pointers, just with the bounds-check
>> expanded to 28 bits:
>> (127:112): Bounds(27:12)
>> (111: 64): Address(95:48)
>> ( 63: 60): Tag (0010)
>> ( 59: 48): Bounds(11:0)
>> ( 47: 0): Address(47:0)
>>
>> It is possible that, if it really mattered, a case for XMOV instructions
>> with integrated bounds-checking could be added (to avoid needing to
>> spend a few extra clock cycles on external bounds checks).
>>
>>
>>
>> Using out-of-band tag bits to make registers and memory "tamper
>> resistant" is an interesting idea. There are a few places where this
>> could be useful.
>>
>> Main issue is how to do this cost-effectively.
>> Option 1: Another specialized L1 cache (undesirable);
>> Option 2: Make cache lines several bits larger.
>> L2 now needs to deal with it, somehow...
>>
>> Most ideas I can think of would either require another specialized
>> cache, or effectively result in non-power-of-2 memory addressing, or both.
>>
>>
>> Any thoughts?...
> <
> Will go don in the history books as another attempt at capabilities.

On 1/27/2022 6:44 PM, Ivan Godard wrote:
> On 1/27/2022 2:48 PM, BGB wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
>> Morello architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and
>> bounds checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing
>> so would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain
>> pointers, and to disallow loading a pointer from memory which has been
>> used for data);
>> ...
>>
>>  From the original thread:
>>    https://www.theregister.com/2022/01/21/arm_morello_testing/
>>    https://www.arm.com/architecture/cpu/morello
>>    https://developer.arm.com/documentation/ddi0606/latest
>> Also found:
>>
>> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>>
>>
>>
>> In effect, it seems like the program can't be allowed to craft or
>> modify its own pointers directly, as code doing so would break its
>> whole memory protection scheme. In effect, pointers would need to be
>> derived from other pointers.
>>
>>
>> I guess it works, but I am slightly skeptical of this idea:
>> Making all the pointers twice the size is not ideal for memory footprint;
>> This would have a potentially significant impact on existing codebases:
>>    They can no longer assume sizeof(long)==sizeof(void *);
>>    Code can no longer bit-twiddle their pointers;
>>    ...
>>
>> While there are ways one would allow for 64-bit pointers, there isn't
>> a good way to do so without (also) blowing a massive hole in the whole
>> security scheme.
>>
>> It effectively means that any code which relies on NaN tagging, tagged
>> pointers, or other sorts of pointer hackery, would need to rewritten
>> to work on such an architecture.
>>
>>
>>
>> I slightly prefer my "throw Unix-style file protections and ACLs at
>> RAM" approach, since this need not have any visible impact on how C
>> operates (pointers can remain 64 bits, code is free to bit-twiddle its
>> pointers, ...).
>>
>> Some properties of capabilities could be emulated (albeit imperfectly)
>> by using more conventional ASLR strategies (would be more effective in
>> an expanded 96-bit address space, as this could make it
>> computationally infeasible to "guess" the addresses to things).
>>
>> Though, admittedly, if I were designing it now, I would likely have
>> skipped over the UID/GID part of VUGID and gone for using ACL checks
>> exclusively (the ACL check mechanism is more "general purpose" and
>> also takes up fewer bits in the TLB and page-table entries due to not
>> needing to store the access-mode bits directly in the TLBE/PTE).
>>
>>
>> In other cases, the protections from "true" capabilities become
>> unnecessary, since an MMU ACL check does not need to care how one
>> arrived at an address, merely whether or not the executing code is
>> allowed to access it (also cheaper to implement as well, at least with
>> the ACL miss logic offloaded to an ISR).
>>
>>
>> One can also gain implicit bounds checking via the huge expanses of
>> "nothingness" which would surround most larger memory allocations.
>>
>> Within 96-bit land, it could make sense to enforce a minimum distance
>> of 32GB between mmaps, as this would in effect make it "technically
>> impossible" for an out-of-bounds access on one object to collide with
>> any other object.
>>
>>
>> The "big expanse of nothingness" approach would not offer protection
>> for normal heap objects or stack allocations, but capabilities will
>> not offer this either unless there are instructions to compose a
>> smaller bounds-checked capability from a bigger one (would require
>> more looking into).
>>
>>
>> In my case, there were separate (software enforced) schemes for
>> bounds-checked arrays (as part of the pointer type-tagging scheme):
>>    0xxx: Pointer, xxx=TypeTag
>>    2xxx: Bounded Array, xxx=size (0..4095)
>>    Cxxx: Displaced Array, xxx=Offset (0..4095)
>>
>>
>> Similar could be done with XMOV pointers, just with the bounds-check
>> expanded to 28 bits:
>>    (127:112): Bounds(27:12)
>>    (111: 64): Address(95:48)
>>    ( 63: 60): Tag (0010)
>>    ( 59: 48): Bounds(11:0)
>>    ( 47:  0): Address(47:0)
>>
>> It is possible that, if it really mattered, a case for XMOV
>> instructions with integrated bounds-checking could be added (to avoid
>> needing to spend a few extra clock cycles on external bounds checks).
>>
>>
>>
>> Using out-of-band tag bits to make registers and memory "tamper
>> resistant" is an interesting idea. There are a few places where this
>> could be useful.
>>
>> Main issue is how to do this cost-effectively.
>>    Option 1: Another specialized L1 cache (undesirable);
>>    Option 2: Make cache lines several bits larger.
>>      L2 now needs to deal with it, somehow...
>>
>> Most ideas I can think of would either require another specialized
>> cache, or effectively result in non-power-of-2 memory addressing, or
>> both.
>>
>>
>> Any thoughts?...
>
> Many thoughts.
>
> I'm a great fan of caps systems; I wish Mill could have been a caps
> architecture.
>
> The problem is that a move to 128 bit pointers breaks existing codes
> that assume what the pointer size is, due to externally defined
> interfaces such as data layouts. The market was willing to tolerate such
> breaks in the moves 16->32->64 bit addresses because the older, smaller
> sizes became hopelessly unusable. But move to 126? No - people will say
> "My code runs fine with 64-bit pointers. These caps thingummies claim to
> offer a bunch of new benefits, but I don't yet have to have them, so
> I'll look into it - someday."
>

Similar issue.

For BJX2, the default pointer size remains at 64 bits with a 48-bit
logical address (luckily the VUGID/ACL checks don't care about this part).

There is a 96-bit address space via XMOV and "int __huge *addr;" and
similar, but I don't expect this would see much beyond niche usage.

Though, XMOV does have the niche use-case of being able to fake separate
virtual address spaces within a single larger virtual address space.

Say, spawn a thread in a different quadrant, and it may as well be in
its own 48-bit address space. Short of it being able to decipher the
ASLR addresses, it has little chance of being able to figure out the
addresses of other stuff within the larger shared virtual address space.

It will then use 48 bit addresses via 64 bit pointers within its own
quadrant, and able to be unaware as to what might exist within the other
quadrants.

Though, there is a potential risk here if the OS kernel is always in, say:
0000_00000000:8000_xxxxxxxx

Or, the root process always in "quadrant zero", ...

This would be somewhat easy to guess, so ideally the OS kernel and
similar would need to itself be ASLR'ed (in addition to protection ring
and VUGID checks and similar).

So, at least, the bigger pointers in my case can give a bigger address
space (unlike Morello / CHERI).

> A secondary issue is that there's an enormous mass of unstructured
> monolithic code out there, that would need majorly redesign to use caps
> for anything more than bounds checking. Bounds checking is the least of
> the gain from caps.But the legacy data format issue is why we went with
> a grant system. It helps that we can do bounds checking without needing
> expanded data.
>

Yeah.

The need for significant redesign is a big concern of mine regarding
capability addressing.

I suspect this is a major advantage of my VUGID/ACL system: it is pretty
much invisible to the application...

You could also bolt it onto ARM, or x64, or RISC-V, and pretty much
nothing would need to notice that anything was different.

Well, apart from the ability to now impose additional security checks on
memory objects within a process, or to spawn threads under more
restrictive keyrings, ...

On 1/27/2022 6:38 PM, BGB wrote:

snip

> Most historical machines which have tried using capability addressing
> have either died off, or resulted in machines where their later
> descendants abandoned the use of capabilities (eg: System/38 was
> replaced by systems built on the Power ISA, ...).

I thought that when IBM switched from a proprietary processor to a Power
for the AS/400, they had a custom variant chip that had 65 bits and
used that extra bit for the protection scheme.

But I may be misremembering. :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 1/27/2022 10:20 PM, Stephen Fuld wrote:
> On 1/27/2022 6:38 PM, BGB wrote:
>
> snip
>
>> Most historical machines which have tried using capability addressing
>> have either died off, or resulted in machines where their later
>> descendants abandoned the use of capabilities (eg: System/38 was
>> replaced by systems built on the Power ISA, ...).
>
> I thought that when IBM switched from a proprietary processor to a Power
>  for the AS/400, they had a custom variant chip that had 65 bits and
> used that extra bit for the protection scheme.
>
> But I may be misremembering.  :-(
>
>
>

AS400 apps continued to run as before, with caps; power is in effect
the micro-engine. Same as the Unisys systems, where (I think still) the
micro-engine is x86, but the apps still see the original ISA.

Ivan Godard wrote:
> On 1/27/2022 4:23 PM, Stefan Monnier wrote:
>>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
>>> Morello
>>> architecture, which is effectively a modified Aarch64, except:
>>> Expands GPRs to 129 bits (internally);
>>> Integer ISA remains 64-bit;
>>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>>> addresses (the rest of the bits are used as protection flags and bounds
>>> checks);
>>> In effect, all pointers expand to 128 bits in memory;
>>> Code isn't allowed to craft its own pointers (directly) because doing so
>>> would break its memory protection scheme (the 129th bit is stored
>>> separately, seemingly to track which memory locations contain
>>> pointers, and
>>> to disallow loading a pointer from memory which has been used for data);
>>
>> AFAIK the main issue with such things is what they do about dangling
>> pointers, i.e. dangling capabilities.  Do they rely on a GC that's part
>> of the "trusted runtime"?  or do they disallow deallocation altogether?
>> or do they rely on address-space randomization to make such dangling
>> capabilities "harmless" (they'll hopefully only make you crash but are
>> harder to exploit)?
>>
>> The designs that keep the actual capabilities in a kind of
>> separate/secured table (so the untrusted code only handles references to
>> these capabilities and can thus do anything it wants within its sandbox
>> without needing any special XX=1bit values) have a much easier time
>> since they can much more easily ensure the absence of
>> references/capabilities before deallocating resources, or they can mark
>> them as dead).
>>
>
> Isn't it Terje who says anything can be done with another layer of
> indirection?

I do say that but it was old knowledge long before I first quoted it.
>
> Revoke of permissions (and scavenge of permitted resources) is a very
> hard problem in any permission system, including caps - and paging
> tables too for that matter. These days narrow-cast caps (a.k.a handles)
> typically use usecount GC. Which in practice works OK for well-behaved
> users, Let a DOS attacker on your system though...

Handles does work, it can probably be done well within a binary order of
magnitude without opening up lots of DOS opportunities.

OTOH, we have lots of examples, typically related to IO (mmap, direct
IO, remote DMA etc) where performance requirements trump almost
everything else even though we have had handle-based file/stream apis
since forever.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

BGB <cr88192@gmail.com> wrote:
> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
> Morello architecture, which is effectively a modified Aarch64, except:
> Expands GPRs to 129 bits (internally);
> Integer ISA remains 64-bit;
> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> addresses (the rest of the bits are used as protection flags and bounds
> checks);
> In effect, all pointers expand to 128 bits in memory;
> Code isn't allowed to craft its own pointers (directly) because doing so
> would break its memory protection scheme (the 129th bit is stored
> separately, seemingly to track which memory locations contain pointers,
> and to disallow loading a pointer from memory which has been used for data);
> ...
>
> From the original thread:
> https://www.theregister.com/2022/01/21/arm_morello_testing/
> https://www.arm.com/architecture/cpu/morello
> https://developer.arm.com/documentation/ddi0606/latest
> Also found:
>
> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst

Declaration of interest: I'm on the CHERI team at the University of
Cambridge, although speaking personally.

Morello is an implementation of the CHERI capability architecture. CHERI is
archtitecture-neutral, but every implementation needs a certain
amount of localisation for the target architecture. Morello is an
experimental localisation for ARMv8, and a specific implementation in a chip
to evaluate whether that's any good, in a modern CPU.

More CHERI background:
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf

Therefore, in most cases the discussion is about CHERI, as an abstract
model, rather than Morello, which is an implementation of the model. There
will of course be details about the specific implementation in ARMv8, and
that's one thing the Morello programme aims to find out.

> In effect, it seems like the program can't be allowed to craft or modify
> its own pointers directly, as code doing so would break its whole memory
> protection scheme. In effect, pointers would need to be derived from
> other pointers.
>
>
> I guess it works, but I am slightly skeptical of this idea:
> Making all the pointers twice the size is not ideal for memory footprint;
> This would have a potentially significant impact on existing codebases:
> They can no longer assume sizeof(long)==sizeof(void *);
> Code can no longer bit-twiddle their pointers;
> ...
>
> While there are ways one would allow for 64-bit pointers, there isn't a
> good way to do so without (also) blowing a massive hole in the whole
> security scheme.

First thing to say is that CHERI is optional. You can still use 64 bit
pointers in the usual load/store instructions, and have them checked against
a 'default data capabiility' in a coarse grained way. In this 'hybrid' mode
you can then choose particular pointers to be capabilities (via source
annotations). That doesn't get you quite so much fine grained protection by
default, but it means you can pay the cost when you want to and not when you
don't.

In many cases, code is not massively pointer heavy and so the cost is
relatively small. Some code uses pointers more densely (eg Javascript
runtimes) and that might need more careful design (eg use of hybrid mode).
But a lot of C you can just compile up with every pointer be a capability in
we're talking single-digits percent.

> It effectively means that any code which relies on NaN tagging, tagged
> pointers, or other sorts of pointer hackery, would need to rewritten to
> work on such an architecture.

True. It is questionable whether some of those are good ideas, however...
(it seems to be a truth universally acknowledged that, whenever a system is
designed, somebody will come up with cunning wheezes that use it in ways it
was never designed for. Which is fine, until the next system comes along
that doesn't work the same way)

In general the code changes are relatively limited, and often mechanical.
For example in 6 million LOC of KDE, 0.026% needed modification:
https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf

> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
> approach, since this need not have any visible impact on how C operates
> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
> ...).

How would that work within a typical C program? Are you checking those
things with software, or with hardware?

There have been a number of approaches which involve keeping shadow state
out of normal RAM, eg Intel MPX. That's fine if you have a relatively small
amount of shadow state, but doesn't scale very well.

> Some properties of capabilities could be emulated (albeit imperfectly)
> by using more conventional ASLR strategies (would be more effective in
> an expanded 96-bit address space, as this could make it computationally
> infeasible to "guess" the addresses to things).

The problem with ASLR is that it only holds until you have sight of a
pointer. Once you have a pointer, you can trivially compute the ASLR slide.
You can mitigate to some extent by sparse linking, putting each object at a
different ASLR offset, but that loses some of your spatial locality
(thrashing your TLB etc).

> Though, admittedly, if I were designing it now, I would likely have
> skipped over the UID/GID part of VUGID and gone for using ACL checks
> exclusively (the ACL check mechanism is more "general purpose" and also
> takes up fewer bits in the TLB and page-table entries due to not needing
> to store the access-mode bits directly in the TLBE/PTE).
>
>
> In other cases, the protections from "true" capabilities become
> unnecessary, since an MMU ACL check does not need to care how one
> arrived at an address, merely whether or not the executing code is
> allowed to access it (also cheaper to implement as well, at least with
> the ACL miss logic offloaded to an ISR).

I'm not sure I quite follow. What extra state are you adding to implement
the ACL? In the page table, or elsewhere?

We already have R/W/X permissions of course, are you adding a generic 'ACL
ID' which is then looked up in a shadow list? How do you represent who is
allowed and who is not in the list?

> Within 96-bit land, it could make sense to enforce a minimum distance of
> 32GB between mmaps, as this would in effect make it "technically
> impossible" for an out-of-bounds access on one object to collide with
> any other object.

What's special about 32GB? Why can an attacker not craft a 32GB increase?
(I accept it's harder to do this accidentally)

> Similar could be done with XMOV pointers, just with the bounds-check
> expanded to 28 bits:
> (127:112): Bounds(27:12)
> (111: 64): Address(95:48)
> ( 63: 60): Tag (0010)
> ( 59: 48): Bounds(11:0)
> ( 47: 0): Address(47:0)
>
> It is possible that, if it really mattered, a case for XMOV instructions
> with integrated bounds-checking could be added (to avoid needing to
> spend a few extra clock cycles on external bounds checks).

I'm not familiar with XMOV, but how are you enforcing pointer integrity
here? If I can manipulate pointers, what's stopping me crafting one with
whatever bounds I want?

> Using out-of-band tag bits to make registers and memory "tamper
> resistant" is an interesting idea. There are a few places where this
> could be useful.
>
> Main issue is how to do this cost-effectively.
> Option 1: Another specialized L1 cache (undesirable);
> Option 2: Make cache lines several bits larger.
> L2 now needs to deal with it, somehow...
>
> Most ideas I can think of would either require another specialized
> cache, or effectively result in non-power-of-2 memory addressing, or both.

It should be said that CHERI is a point in the space of a tagged memory
architecture. There are a number of others out there, using more tag bits
(up to 64 bits per word). CHERI opts to keep more in-band and only the
single out-of-band tag bit to maintain the in-band integrity. This aims to
keep the costs minimal if you don't use the features. If you're
prepared to pay a higher cost per memory word (more than 1/128 memory
overhead) then there are other things you can do.

Theo

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> AFAIK the main issue with such things is what they do about dangling
> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
> of the "trusted runtime"? or do they disallow deallocation altogether?
> or do they rely on address-space randomization to make such dangling
> capabilities "harmless" (they'll hopefully only make you crash but are
> harder to exploit)?

There are several approaches. One is a GC-like sweep to zap dangling
capabilities. Due to the capability tags we know where the capabilities
are, and which pages are allowed to hold capabilities, and we can skip the
others. That makes it a lot more efficient:

https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2020oakland-cornucopia.pdf

> The designs that keep the actual capabilities in a kind of
> separate/secured table (so the untrusted code only handles references to
> these capabilities and can thus do anything it wants within its sandbox
> without needing any special XX=1bit values) have a much easier time
> since they can much more easily ensure the absence of
> references/capabilities before deallocating resources, or they can mark
> them as dead).

Simply zapping a tag is enough to turn a capability into not-a-capability.
So ensuring the absence of capabilities is easy, it's making sure you keep
the ones that you're still supposed to have is where the work comes in.

Theo

Ivan Godard <ivan@millcomputing.com> wrote:
> The problem is that a move to 128 bit pointers breaks existing codes
> that assume what the pointer size is, due to externally defined
> interfaces such as data layouts. The market was willing to tolerate such
> breaks in the moves 16->32->64 bit addresses because the older, smaller
> sizes became hopelessly unusable. But move to 126? No - people will say
> "My code runs fine with 64-bit pointers. These caps thingummies claim to
> offer a bunch of new benefits, but I don't yet have to have them, so
> I'll look into it - someday."

That turns out to be less than you might think. For a lot of the codebases
we've looked at, they've already gone through the 32->64 transition in the
recent (well, 15 years) past, and a lot of that cleanup already happened. A
lot of code still runs on both 32 and 64 (eg i386 and x86-64) and the
necessary changes made it pointer length agnostic.

What's more troublesome is people stuffing pointers inside integers -
uint64_t foo = (uint64_t) &bar;
but that's what intptr_t exists for, and it's not a lot of work to make it
this:
intptr_t foo = (intptr_t) &bar;

If that's something you're stuffing in a file or putting down a network
socket you're doing it wrong: pointers are not supposed to leak from address
spaces, and with the rise of ASLR it's not very meaningful to do this.

(and of course the same applies to the 32/64 transition)

It's not always plain sailing of course, and there are some things that are
particularly troublesome (eg language runtimes) but much application code
isn't so tricky.

We're mostly looking at open source code, though, which tends to undergo
some kind of modernisation as development proceeds. It's possible there are
some antique closed-source codebases out there that are still targeting 32
bit machines, but they're going to suffer other problems in the modern
world.

> A secondary issue is that there's an enormous mass of unstructured
> monolithic code out there, that would need majorly redesign to use caps
> for anything more than bounds checking. Bounds checking is the least of
> the gain from caps.But the legacy data format issue is why we went with
> a grant system. It helps that we can do bounds checking without needing
> expanded data.

Compartmentalisation, ie how to chop things up into distrusting pieces, is
indeed a much harder problem and one where there isn't one true answer. The
plan is to give people the tools and see what they can do with them.

Theo

On 1/28/2022 4:39 AM, Theo Markettos wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> AFAIK the main issue with such things is what they do about dangling
>> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
>> of the "trusted runtime"? or do they disallow deallocation altogether?
>> or do they rely on address-space randomization to make such dangling
>> capabilities "harmless" (they'll hopefully only make you crash but are
>> harder to exploit)?
>
> There are several approaches. One is a GC-like sweep to zap dangling
> capabilities. Due to the capability tags we know where the capabilities
> are, and which pages are allowed to hold capabilities, and we can skip the
> others. That makes it a lot more efficient:

That's why the tagged-architecture Burroughs mainframes had the MSEQ
(Masked Search for Equal) instruction. The mask and comparison were full
width including the tag, so you could pick up any word (51 bits counting
3 bits tag) with a non-data tag. The search engine could run at RAM
speed (ferrite core memory, not DRAM).

On 1/28/2022 6:30 AM, Theo Markettos wrote:
> BGB <cr88192@gmail.com> wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
>> Morello architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and bounds
>> checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing so
>> would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain pointers,
>> and to disallow loading a pointer from memory which has been used for data);
>> ...
>>
>> From the original thread:
>> https://www.theregister.com/2022/01/21/arm_morello_testing/
>> https://www.arm.com/architecture/cpu/morello
>> https://developer.arm.com/documentation/ddi0606/latest
>> Also found:
>>
>> https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
>
> Declaration of interest: I'm on the CHERI team at the University of
> Cambridge, although speaking personally.
>
> Morello is an implementation of the CHERI capability architecture. CHERI is
> archtitecture-neutral, but every implementation needs a certain
> amount of localisation for the target architecture. Morello is an
> experimental localisation for ARMv8, and a specific implementation in a chip
> to evaluate whether that's any good, in a modern CPU.
>
> More CHERI background:
> https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf
> https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-947.pdf
> https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf
>
> Therefore, in most cases the discussion is about CHERI, as an abstract
> model, rather than Morello, which is an implementation of the model. There
> will of course be details about the specific implementation in ARMv8, and
> that's one thing the Morello programme aims to find out.
>

OK.

>> In effect, it seems like the program can't be allowed to craft or modify
>> its own pointers directly, as code doing so would break its whole memory
>> protection scheme. In effect, pointers would need to be derived from
>> other pointers.
>>
>>
>> I guess it works, but I am slightly skeptical of this idea:
>> Making all the pointers twice the size is not ideal for memory footprint;
>> This would have a potentially significant impact on existing codebases:
>> They can no longer assume sizeof(long)==sizeof(void *);
>> Code can no longer bit-twiddle their pointers;
>> ...
>>
>> While there are ways one would allow for 64-bit pointers, there isn't a
>> good way to do so without (also) blowing a massive hole in the whole
>> security scheme.
>
> First thing to say is that CHERI is optional. You can still use 64 bit
> pointers in the usual load/store instructions, and have them checked against
> a 'default data capabiility' in a coarse grained way. In this 'hybrid' mode
> you can then choose particular pointers to be capabilities (via source
> annotations). That doesn't get you quite so much fine grained protection by
> default, but it means you can pay the cost when you want to and not when you
> don't.
>

Admittedly, my skimming of the specs was fairly quick and dirty (mostly
triggered by a thread on comp.lang.c), so I may have missed a few things.

> In many cases, code is not massively pointer heavy and so the cost is
> relatively small. Some code uses pointers more densely (eg Javascript
> runtimes) and that might need more careful design (eg use of hybrid mode).
> But a lot of C you can just compile up with every pointer be a capability in
> we're talking single-digits percent.
>

Yeah, it is mostly things like JavaScript, LuaJit, etc, where I expect
that many of the issues would come up.

While I could note some problem areas in the Quake engine family, my
ports of these to 64-bits already hacked over a few cases in a way which
"should" tolerate further widening.

Namely, there were a few places where 32-bit addresses were used without
any good way to widen things to 64 bits and not break things (such as
the "progs.dat" VM in Quake 1), I had instead switched to relative
addressing (in Quake 1, treating these addresses as being relative to
the "hunk base", as I had noted that they tended not to point to
anything outside of this area).

It had seemed like one could construct capabilities to things using a
collection of "global capabilities" as a base, but the existence of such
things would not be a good thing for the security model.

>> It effectively means that any code which relies on NaN tagging, tagged
>> pointers, or other sorts of pointer hackery, would need to rewritten to
>> work on such an architecture.
>
> True. It is questionable whether some of those are good ideas, however...
> (it seems to be a truth universally acknowledged that, whenever a system is
> designed, somebody will come up with cunning wheezes that use it in ways it
> was never designed for. Which is fine, until the next system comes along
> that doesn't work the same way)
>
> In general the code changes are relatively limited, and often mechanical.
> For example in 6 million LOC of KDE, 0.026% needed modification:
> https://www.capabilitieslimited.co.uk/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf
>

OK.

>> I slightly prefer my "throw Unix-style file protections and ACLs at RAM"
>> approach, since this need not have any visible impact on how C operates
>> (pointers can remain 64 bits, code is free to bit-twiddle its pointers,
>> ...).
>
> How would that work within a typical C program? Are you checking those
> things with software, or with hardware?
>

The actual ACL enforcement is done in hardware via the MMU.

From the software POV, this part is pretty much exactly the same as
more traditional "protection ring" MMU.

The main difference is that there is a supervisor-only register (KRR, or
Keyring Register), which generally user-land code is not allowed to
access (and which holds their keys within the VUGID/ACL system).

Basically, the MMU contains several structures:
A TLB, implemented as a larger 4-way set-associative cache.
It holds a mapping between virtual and physical addresses.
It also contains information about memory protection, ...
An ACL cache, which is a much smaller fully-associative cache.
It is currently 4-entry, but 8-entry would likely be better.
It encodes, for a pair of IDs A accessing B, what is allowed.

So, the MMU sees that ACL checking is used for a page (during the TLB
fetch), then checks this against the entries in the ACL cache, checking
for a match with one of the keys held in the active KRR (Keyring
Register) which itself holds up to 4 IDs (same format as the ACLID, *).

If a match is found, it selects one of the appropriate groups of
protection bits (organized based on "User/Group/Other").

These bits are combined with the top-level page bits from the TLB to
determine what level of access is allowed for the page as a whole.

*: In the current implementation, ACLID values are treated as an
unsigned 16-bit number, with 0 being special (0 either disables this
check, or is ignored, depending on its location).

The MMU however neither performs its own page walks nor ACL lookups.

If there isn't a matching page, the CPU generates a TLB Miss interrupt,
and the OS or similar will need to walk the page tables or similar to
resolve the issue (however, since this part is software, other
"non-page-table" structures are also possible).

So, software walks the table, builds the TLB entry, and then hands it
back to the MMU via a "LDTLB" instruction. After this point, the ISR
returns, and the CPU (again) tries to access the page in question (this
may or may not generate interrupts, the process will continue until no
more interrupts are generated).

If there is a mismatch with the ACL cache (entries in the keyring don't
match those in the ACL cache), the MMU will generate an "ACL Miss"
interrupt (very similar to the TLB Miss scenario).

The ACLID is looked up in a structure vaguely resembling another page
table, with leaf entries which point to associative arrays holding
mappings between the current ACLID and KRR keys. The entry matching what
is requested is then fetched from the table, and sent back to the MMU
via an "LDACL" instruction, or if no match is seen, the ISR will
generate a "No Access" entry, and load this into this via LDACL.

Ivan Godard <ivan@millcomputing.com> wrote:
> That's why the tagged-architecture Burroughs mainframes had the MSEQ
> (Masked Search for Equal) instruction. The mask and comparison were full
> width including the tag, so you could pick up any word (51 bits counting
> 3 bits tag) with a non-data tag. The search engine could run at RAM
> speed (ferrite core memory, not DRAM).

Another trick is having a hierarchical tag cache. One bit in an upper level
of the cache refers to (for example) an entire page, whose individual tag
bits are stored in the lowest level. The upper level bit being set
indicates that there's at least one capability present in the page. That
makes it very easy to skip pages which don't contain capabilities when
scanning.

It's also possible to mark pages in the page table as to whether
capabilities can be stored there, which also constrains where they can go.

Theo

On 1/28/2022 1:48 PM, Theo Markettos wrote:
> Ivan Godard <ivan@millcomputing.com> wrote:
>> That's why the tagged-architecture Burroughs mainframes had the MSEQ
>> (Masked Search for Equal) instruction. The mask and comparison were full
>> width including the tag, so you could pick up any word (51 bits counting
>> 3 bits tag) with a non-data tag. The search engine could run at RAM
>> speed (ferrite core memory, not DRAM).
>
> Another trick is having a hierarchical tag cache. One bit in an upper level
> of the cache refers to (for example) an entire page, whose individual tag
> bits are stored in the lowest level. The upper level bit being set
> indicates that there's at least one capability present in the page. That
> makes it very easy to skip pages which don't contain capabilities when
> scanning.
>
> It's also possible to mark pages in the page table as to whether
> capabilities can be stored there, which also constrains where they can go.
>
> Theo

That approach permits relatively fast search, but adds to the expense of
store and memcpy (etc). As it is common to pass caps (pointers) as
function args and results, the call overhead increases noticeably unless
you have special caching that covers the stack and never write it back -
but that exposes an attack surface in inter-thread references in multicore.

There doesn't seem to be an easy solution for caps, unless you are
Samsung and can make caps memory as cheap as regular.

On 1/28/2022 1:00 AM, Ivan Godard wrote:
> On 1/27/2022 10:20 PM, Stephen Fuld wrote:
>> On 1/27/2022 6:38 PM, BGB wrote:
>>
>> snip
>>
>>> Most historical machines which have tried using capability addressing
>>> have either died off, or resulted in machines where their later
>>> descendants abandoned the use of capabilities (eg: System/38 was
>>> replaced by systems built on the Power ISA, ...).
>>
>> I thought that when IBM switched from a proprietary processor to a
>> Power   for the AS/400, they had a custom variant chip that had 65
>> bits and used that extra bit for the protection scheme.
>>
>> But I may be misremembering.  :-(
>>
>>
>>
>
> AS400 apps continued  to run as before, with caps; power is in effect
> the micro-engine. Same as the Unisys systems, where (I think still) the
> micro-engine is x86, but the apps still see the original ISA.

As far as I understood it, the Power ISA was being used to run something
more like an emulator. So, the original capability system was then
implemented in software rather than hardware.

May be wrong on the specifics, as no real first-hand experience with this.

According to BGB <cr88192@gmail.com>:
>>> I thought that when IBM switched from a proprietary processor to a
>>> Power   for the AS/400, they had a custom variant chip that had 65
>>> bits and used that extra bit for the protection scheme.

>> AS400 apps continued  to run as before, with caps; power is in effect
>> the micro-engine. Same as the Unisys systems, where (I think still) the
>> micro-engine is x86, but the apps still see the original ISA.
>
>As far as I understood it, the Power ISA was being used to run something
>more like an emulator. So, the original capability system was then
>implemented in software rather than hardware.

More or less. The virtual architecture is called
Technology-Independent Machine Interface (TIMI). The first time a
program is run on a macine, the TIMI code is translated into the local
machine code, then the program runs.

It's a very high level operating system that includes a relational database
and other things that would be separate applications on conventional systems.

On Unisys I don't know whether they do instruction at a time emulation, whole
program translation, or something in between like per-routine JIT.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 1/27/2022 6:23 PM, Stefan Monnier wrote:
>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM Morello
>> architecture, which is effectively a modified Aarch64, except:
>> Expands GPRs to 129 bits (internally);
>> Integer ISA remains 64-bit;
>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>> addresses (the rest of the bits are used as protection flags and bounds
>> checks);
>> In effect, all pointers expand to 128 bits in memory;
>> Code isn't allowed to craft its own pointers (directly) because doing so
>> would break its memory protection scheme (the 129th bit is stored
>> separately, seemingly to track which memory locations contain pointers, and
>> to disallow loading a pointer from memory which has been used for data);
>
> AFAIK the main issue with such things is what they do about dangling
> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
> of the "trusted runtime"? or do they disallow deallocation altogether?
> or do they rely on address-space randomization to make such dangling
> capabilities "harmless" (they'll hopefully only make you crash but are
> harder to exploit)?
>

I guess apparently people have worked around some of these issues.

But, yeah, ASLR is potentially also effective, given enough bits.

Many traditional weaknesses of ASLR come from not having enough bits in
the address space, leading to it being possible to guess or brute force
the addresses.

So, say:
32-bit address space, you can get maybe a few bits of entropy.
Trivial to brute force if the code doesn't crash first.
If one has 100s of MB of heap (typical) there is little "void space"
The randomization is typically "offset jitter";
RNG based alloc would quickly fragment the space.
...
48-bit space, can get a little more entropy (say, ~ 12 bits or so).
This can render "slides" mostly impractical;
Large enough that one can use RNG to allocate address space;
However, a "clever" algo could still brute-force things;
...
96-bit, significant entropy and voids are possible;
It can also become infeasible to brute-force addresses.

Known layout of things like target binaries or libraries would be a
problem, but as noted elsewhere, randomized shuffling in the compiler
should help here (main weakness would be long-lived "stale" binaries).
In this case, the compiler's RNG needs to be unpredictable though (so
that every build is unique).

If the binaries were compiled via an AOT though, then the AOT could
impose a maximum lifespan (forcing periodic regeneration).

A capability system would not necessarily be immune to attacks on known
library layouts, say:
Program A uses library B;
Program A has Read+Exec to B
Exec so A can call into it;
Read so that B can return string literals / etc to A.
B has a capability to C (secure) in a known location;
A then "steals" the capability via loading it from this location.
Granted, less of an issue if Read and ReadCapability are separate;
Still an issue if ReadCapability is allowed for struct-passing, ...

This would be much harder is the compiler randomizes B's layout.

Things like ACL checks would also help, since even if one can read the
pointer, unless A has permission to use pointers into C, then the
pointer is "mostly useless".

Though, does imply a need for an A->B call to be able to temporarily add
its own entry into the keyring, and then restore the prior keyring when
returning to A.

How to securely and efficiently do keyring updates (in a general sense)
has thus far remained an unresolved issue. I had considered special
semi-privledged instructions to save/restore/update the keyring. My
previous ideas had involved hardware-based encryption, but this is still
an issue (no real good way to get it both "sufficiently strong" and also
"sufficiently cheap").

Another (more recent, but more limited) strategy (which avoids the need
for an actual keyring update) is to add a virtual key based on the page
that is currently being executed (if the page is set to the appropriate
mode).

So, A has its initial KRR, and calls B. Because execution is inside of
B's pages, it (virtually) adds B's ACLID to the keyring, and this gains
any special accesses that B's ACLID has. On returning from B (or calling
into C), B's virtual keyring entry disappears (though, a call into C may
add C's ACLID to the keyring in its place).

Though, this does mean that C will not gain any implicit access to B's
data via B's ACLID, since B's ACLID will disappear as soon as control
passes from B to C (though, it may retain access to A's data if A's
ACLID is within the thread level KRR).

This partly works based on the idea that access to an ACLID will not
necessarily have the same privilege as when executing as said ACLID
(where the ACLID functions instead as a VUGID).

Though, my current implementation of this mechanism is a bit of an ugly
hack: It is passed via side-channels between the L1 I$ and MMU, since
this information would have been a bit awkward and ugly to pass via the
ringbus.

Actually, more specifically, it is implemented as a hack by using
"non-interrupting-interrupts" as a signaling mechanism (eg, the pathway
that would normally be used for raising interrupts is being used, if
effect, so that the TLB can send "smoke signals" back to the L1 I$ and
similar about the request it is waiting on).

One potential concern is that, since this is based on where code is
being executed from, rather than how it got there, this does leave the
potential attack surface of being able to jump to unorthodox entry
points within a library (beyond just its exports). ASLR can help at
least (unless hostile code uses pattern matching to search for a
particular machine-code sequence).

Another possibility being to add a level of indirection and only allow
A->B calls via dedicated trampolines (T). So, A has execute to T, T has
execute to B, but A does not have execute to B). This would at least
stop A from being able to decide its own entry points (but, would
increase the total number of ACLs in use).

> The designs that keep the actual capabilities in a kind of
> separate/secured table (so the untrusted code only handles references to
> these capabilities and can thus do anything it wants within its sandbox
> without needing any special XX=1bit values) have a much easier time
> since they can much more easily ensure the absence of
> references/capabilities before deallocating resources, or they can mark
> them as dead).
>

I had considered schemes like this, but didn't do much because (at a
high level) there was no obvious difference between what one could do
via a handle+offset scheme, and what one could do via the existing MMU.

For example, the TLB-Miss handler could easily see the address falls
within the range assigned to a descriptor table, and pull information
from this table rather than using the page table (and, in effect, the
use of a page table itself is more of a convention than an architectural
requirement with a software-managed TLB).

So, no special hardware support needed, could fake something like an x86
style GDT or LDT via the MMU, provided the limitation that the base and
limit are page aligned (well, and probably that one flushes the TLB when
updating or revoking these descriptors).

On 1/29/2022 8:35 AM, BGB wrote:
> On 1/28/2022 1:00 AM, Ivan Godard wrote:
>> On 1/27/2022 10:20 PM, Stephen Fuld wrote:
>>> On 1/27/2022 6:38 PM, BGB wrote:
>>>
>>> snip
>>>
>>>> Most historical machines which have tried using capability
>>>> addressing have either died off, or resulted in machines where their
>>>> later descendants abandoned the use of capabilities (eg: System/38
>>>> was replaced by systems built on the Power ISA, ...).
>>>
>>> I thought that when IBM switched from a proprietary processor to a
>>> Power   for the AS/400, they had a custom variant chip that had 65
>>> bits and used that extra bit for the protection scheme.
>>>
>>> But I may be misremembering.  :-(
>>>
>>>
>>>
>>
>> AS400 apps continued  to run as before, with caps; power is in effect
>> the micro-engine. Same as the Unisys systems, where (I think still)
>> the micro-engine is x86, but the apps still see the original ISA.
>
> As far as I understood it, the Power ISA was being used to run something
> more like an emulator. So, the original capability system was then
> implemented in software rather than hardware.
>
> May be wrong on the specifics, as no real first-hand experience with this.

Yes, exactly. It's only a matter of viewpoint whether you see such a
system as an emulator or as a micro-architecture.

On Saturday, January 29, 2022 at 1:10:01 PM UTC-6, BGB wrote:
> On 1/27/2022 6:23 PM, Stefan Monnier wrote:
> >> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM Morello
> >> architecture, which is effectively a modified Aarch64, except:
> >> Expands GPRs to 129 bits (internally);
> >> Integer ISA remains 64-bit;
> >> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> >> addresses (the rest of the bits are used as protection flags and bounds
> >> checks);
> >> In effect, all pointers expand to 128 bits in memory;
> >> Code isn't allowed to craft its own pointers (directly) because doing so
> >> would break its memory protection scheme (the 129th bit is stored
> >> separately, seemingly to track which memory locations contain pointers, and
> >> to disallow loading a pointer from memory which has been used for data);
> >
> > AFAIK the main issue with such things is what they do about dangling
> > pointers, i.e. dangling capabilities. Do they rely on a GC that's part
> > of the "trusted runtime"? or do they disallow deallocation altogether?
> > or do they rely on address-space randomization to make such dangling
> > capabilities "harmless" (they'll hopefully only make you crash but are
> > harder to exploit)?
> >
> I guess apparently people have worked around some of these issues.
>
> But, yeah, ASLR is potentially also effective, given enough bits.
>
I just read up on ASLR and found:
http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
<
Another attack surface that is not present in My 66000 implementations
under consideration.....
The small implementation 1.3-wide does not need/use branch prediction
The large implementation 6.0-wide does not use a BTB -- it has something
that smells a lot like a BTB but is connected to ~300 other bits and is fully
tag compared. Only a hashed vector of BC are used and these do not
predict taken or untaken, but agree and disagree.
>
> Many traditional weaknesses of ASLR come from not having enough bits in
> the address space, leading to it being possible to guess or brute force
> the addresses.
<
Needing a BTB for performance and not checking all of the address bits
in a tag or hashing the address bits into a complete tag opens the door
to exploits. Microarchitectural state becomes visible via a high precision
timer by allowing for the measurement of instruction delay.
>
> So, say:
> 32-bit address space, you can get maybe a few bits of entropy.
> Trivial to brute force if the code doesn't crash first.
> If one has 100s of MB of heap (typical) there is little "void space"
> The randomization is typically "offset jitter";
> RNG based alloc would quickly fragment the space.
> ...
> 48-bit space, can get a little more entropy (say, ~ 12 bits or so).
> This can render "slides" mostly impractical;
> Large enough that one can use RNG to allocate address space;
> However, a "clever" algo could still brute-force things;
> ...
> 96-bit, significant entropy and voids are possible;
> It can also become infeasible to brute-force addresses.
>
>
> Known layout of things like target binaries or libraries would be a
> problem, but as noted elsewhere, randomized shuffling in the compiler
> should help here (main weakness would be long-lived "stale" binaries).
> In this case, the compiler's RNG needs to be unpredictable though (so
> that every build is unique).
>
> If the binaries were compiled via an AOT though, then the AOT could
> impose a maximum lifespan (forcing periodic regeneration).
>
>
> A capability system would not necessarily be immune to attacks on known
> library layouts, say:
> Program A uses library B;
> Program A has Read+Exec to B
> Exec so A can call into it;
> Read so that B can return string literals / etc to A.
> B has a capability to C (secure) in a known location;
> A then "steals" the capability via loading it from this location.
> Granted, less of an issue if Read and ReadCapability are separate;
> Still an issue if ReadCapability is allowed for struct-passing, ...
>
> This would be much harder is the compiler randomizes B's layout.
>
Since the CAP system remains attackable--what does it actually buy in
terms of security ?
>
>
> Things like ACL checks would also help, since even if one can read the
> pointer, unless A has permission to use pointers into C, then the
> pointer is "mostly useless".
>
>
> Though, does imply a need for an A->B call to be able to temporarily add
> its own entry into the keyring, and then restore the prior keyring when
> returning to A.
>
> How to securely and efficiently do keyring updates (in a general sense)
> has thus far remained an unresolved issue. I had considered special
> semi-privledged instructions to save/restore/update the keyring. My
> previous ideas had involved hardware-based encryption, but this is still
> an issue (no real good way to get it both "sufficiently strong" and also
> "sufficiently cheap").
>
>
>
> Another (more recent, but more limited) strategy (which avoids the need
> for an actual keyring update) is to add a virtual key based on the page
> that is currently being executed (if the page is set to the appropriate
> mode).
>
> So, A has its initial KRR, and calls B. Because execution is inside of
> B's pages, it (virtually) adds B's ACLID to the keyring, and this gains
> any special accesses that B's ACLID has. On returning from B (or calling
> into C), B's virtual keyring entry disappears (though, a call into C may
> add C's ACLID to the keyring in its place).
>
> Though, this does mean that C will not gain any implicit access to B's
> data via B's ACLID, since B's ACLID will disappear as soon as control
> passes from B to C (though, it may retain access to A's data if A's
> ACLID is within the thread level KRR).
>
>
> This partly works based on the idea that access to an ACLID will not
> necessarily have the same privilege as when executing as said ACLID
> (where the ACLID functions instead as a VUGID).
>
> Though, my current implementation of this mechanism is a bit of an ugly
> hack: It is passed via side-channels between the L1 I$ and MMU, since
> this information would have been a bit awkward and ugly to pass via the
> ringbus.
>
>
> Actually, more specifically, it is implemented as a hack by using
> "non-interrupting-interrupts" as a signaling mechanism (eg, the pathway
> that would normally be used for raising interrupts is being used, if
> effect, so that the TLB can send "smoke signals" back to the L1 I$ and
> similar about the request it is waiting on).
>
>
> One potential concern is that, since this is based on where code is
> being executed from, rather than how it got there, this does leave the
> potential attack surface of being able to jump to unorthodox entry
> points within a library (beyond just its exports). ASLR can help at
> least (unless hostile code uses pattern matching to search for a
> particular machine-code sequence).
>
> Another possibility being to add a level of indirection and only allow
> A->B calls via dedicated trampolines (T). So, A has execute to T, T has
> execute to B, but A does not have execute to B). This would at least
> stop A from being able to decide its own entry points (but, would
> increase the total number of ACLs in use).
> > The designs that keep the actual capabilities in a kind of
> > separate/secured table (so the untrusted code only handles references to
> > these capabilities and can thus do anything it wants within its sandbox
> > without needing any special XX=1bit values) have a much easier time
> > since they can much more easily ensure the absence of
> > references/capabilities before deallocating resources, or they can mark
> > them as dead).
> >
> I had considered schemes like this, but didn't do much because (at a
> high level) there was no obvious difference between what one could do
> via a handle+offset scheme, and what one could do via the existing MMU.
>
>
> For example, the TLB-Miss handler could easily see the address falls
> within the range assigned to a descriptor table, and pull information
> from this table rather than using the page table (and, in effect, the
> use of a page table itself is more of a convention than an architectural
> requirement with a software-managed TLB).
>
> So, no special hardware support needed, could fake something like an x86
> style GDT or LDT via the MMU, provided the limitation that the base and
> limit are page aligned (well, and probably that one flushes the TLB when
> updating or revoking these descriptors).

On Friday, January 28, 2022 at 12:31:00 PM UTC+2, Terje Mathisen wrote:
> Ivan Godard wrote:
> > On 1/27/2022 4:23 PM, Stefan Monnier wrote:
> >>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM
> >>> Morello
> >>> architecture, which is effectively a modified Aarch64, except:
> >>> Expands GPRs to 129 bits (internally);
> >>> Integer ISA remains 64-bit;
> >>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
> >>> addresses (the rest of the bits are used as protection flags and bounds
> >>> checks);
> >>> In effect, all pointers expand to 128 bits in memory;
> >>> Code isn't allowed to craft its own pointers (directly) because doing so
> >>> would break its memory protection scheme (the 129th bit is stored
> >>> separately, seemingly to track which memory locations contain
> >>> pointers, and
> >>> to disallow loading a pointer from memory which has been used for data);
> >>
> >> AFAIK the main issue with such things is what they do about dangling
> >> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
> >> of the "trusted runtime"? or do they disallow deallocation altogether?
> >> or do they rely on address-space randomization to make such dangling
> >> capabilities "harmless" (they'll hopefully only make you crash but are
> >> harder to exploit)?
> >>
> >> The designs that keep the actual capabilities in a kind of
> >> separate/secured table (so the untrusted code only handles references to
> >> these capabilities and can thus do anything it wants within its sandbox
> >> without needing any special XX=1bit values) have a much easier time
> >> since they can much more easily ensure the absence of
> >> references/capabilities before deallocating resources, or they can mark
> >> them as dead).
> >>
> >
> > Isn't it Terje who says anything can be done with another layer of
> > indirection?
> I do say that but it was old knowledge long before I first quoted it.

Most often attributed to Dr. David Wheeler.

> >
> > Revoke of permissions (and scavenge of permitted resources) is a very
> > hard problem in any permission system, including caps - and paging
> > tables too for that matter. These days narrow-cast caps (a.k.a handles)
> > typically use usecount GC. Which in practice works OK for well-behaved
> > users, Let a DOS attacker on your system though...
> Handles does work, it can probably be done well within a binary order of
> magnitude without opening up lots of DOS opportunities.
>
> OTOH, we have lots of examples, typically related to IO (mmap, direct
> IO, remote DMA etc) where performance requirements trump almost
> everything else even though we have had handle-based file/stream apis
> since forever.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

On 1/29/2022 12:50 PM, MitchAlsup wrote:
> On Saturday, January 29, 2022 at 1:10:01 PM UTC-6, BGB wrote:
>> On 1/27/2022 6:23 PM, Stefan Monnier wrote:
>>>> Well, elsewhere (on "comp.lang.c"), a topic came up about the ARM Morello
>>>> architecture, which is effectively a modified Aarch64, except:
>>>> Expands GPRs to 129 bits (internally);
>>>> Integer ISA remains 64-bit;
>>>> Uses 128-bit "capabilities" as pointers, which support 56 or 64 bit
>>>> addresses (the rest of the bits are used as protection flags and bounds
>>>> checks);
>>>> In effect, all pointers expand to 128 bits in memory;
>>>> Code isn't allowed to craft its own pointers (directly) because doing so
>>>> would break its memory protection scheme (the 129th bit is stored
>>>> separately, seemingly to track which memory locations contain pointers, and
>>>> to disallow loading a pointer from memory which has been used for data);
>>>
>>> AFAIK the main issue with such things is what they do about dangling
>>> pointers, i.e. dangling capabilities. Do they rely on a GC that's part
>>> of the "trusted runtime"? or do they disallow deallocation altogether?
>>> or do they rely on address-space randomization to make such dangling
>>> capabilities "harmless" (they'll hopefully only make you crash but are
>>> harder to exploit)?
>>>
>> I guess apparently people have worked around some of these issues.
>>
>> But, yeah, ASLR is potentially also effective, given enough bits.
>>
> I just read up on ASLR and found:
> http://www.cs.ucr.edu/~nael/pubs/micro16.pdf
> <
> Another attack surface that is not present in My 66000 implementations
> under consideration.....
> The small implementation 1.3-wide does not need/use branch prediction
> The large implementation 6.0-wide does not use a BTB -- it has something
> that smells a lot like a BTB but is connected to ~300 other bits and is fully
> tag compared. Only a hashed vector of BC are used and these do not
> predict taken or untaken, but agree and disagree.
>>
>> Many traditional weaknesses of ASLR come from not having enough bits in
>> the address space, leading to it being possible to guess or brute force
>> the addresses.
> <
> Needing a BTB for performance and not checking all of the address bits
> in a tag or hashing the address bits into a complete tag opens the door
> to exploits. Microarchitectural state becomes visible via a high precision
> timer by allowing for the measurement of instruction delay.
>>
>> So, say:
>> 32-bit address space, you can get maybe a few bits of entropy.
>> Trivial to brute force if the code doesn't crash first.
>> If one has 100s of MB of heap (typical) there is little "void space"
>> The randomization is typically "offset jitter";
>> RNG based alloc would quickly fragment the space.
>> ...
>> 48-bit space, can get a little more entropy (say, ~ 12 bits or so).
>> This can render "slides" mostly impractical;
>> Large enough that one can use RNG to allocate address space;
>> However, a "clever" algo could still brute-force things;
>> ...
>> 96-bit, significant entropy and voids are possible;
>> It can also become infeasible to brute-force addresses.
>>
>>
>> Known layout of things like target binaries or libraries would be a
>> problem, but as noted elsewhere, randomized shuffling in the compiler
>> should help here (main weakness would be long-lived "stale" binaries).
>> In this case, the compiler's RNG needs to be unpredictable though (so
>> that every build is unique).
>>
>> If the binaries were compiled via an AOT though, then the AOT could
>> impose a maximum lifespan (forcing periodic regeneration).
>>
>>
>> A capability system would not necessarily be immune to attacks on known
>> library layouts, say:
>> Program A uses library B;
>> Program A has Read+Exec to B
>> Exec so A can call into it;
>> Read so that B can return string literals / etc to A.
>> B has a capability to C (secure) in a known location;
>> A then "steals" the capability via loading it from this location.
>> Granted, less of an issue if Read and ReadCapability are separate;
>> Still an issue if ReadCapability is allowed for struct-passing, ...
>>
>> This would be much harder is the compiler randomizes B's layout.
>>
> Since the CAP system remains attackable--what does it actually buy in
> terms of security ?

There are many attack vectors, some of which caps do not address and
some of which *no* security system can address: nothing is proof against
a pretty girl and a suitcase of money. However there are many vectors
that caps *are* proof against and what passes for "security" in
conventional systems are not.

Posters here have been considering systems that address bounds check and
dangling pointers. These are only a part of a true caps system, which
deals with names: in caps, anything you can name has an unforgeable
name, and you can only use such a name for its proper function. For
example, in caps a function return address is a cap, and the only things
you can do with it are return through it and discard it, and you can't
return through anything else; sic transit ROP.

If you don't capify all names then you haven't got a caps system, and
what you didn't do will leave attack holes. In the OP example, there's
third party visibility because there's no way described to do cap
boxing. The example is a good illustration of why boxing is needed,
though I prefer the simpler example of a numeric integration library.