BGB <cr88192@gmail.com> writes:
>On 5/29/2023 3:36 PM, Scott Lurndal wrote:
>IMHO, going much past 128 bits likely goes into diminishing returns
>territory.

The Cray-1 has 4096-bit vector registers, and some of the other vector
machines succeeding it used even longer vectors.

>For practical working sizes for data, 32/64/128 make sense.
> 8 and 16 bits make sense for storage or for SIMD elements.
> 256 or 512 are almost "too big to be useful" in most cases.

If you do some data-parallel processing (where the SIMD stuff shines),
doubling the SIMD width can (in the best case) halve the time needed
to process the data.

>Progressively doubling the size of the registers doesn't seem to make
>sense from a cost POV.

You double only the data and don't need to double rename resources
etc. (IIRC Zen4 splits an AVX-512 instruction into two 256-bit parts
that have independently renamed 256-bit registers, though).

>Say, for example, I would imagine that 32x 512-bit registers will cost a
>fair bit more than 32x 128-bit registers.
>
>But, what can one "actually do with them" to justify the additional
>costs?...

Encoding, decoding, encrypting, wheather prediction, hydrodynamics,
image processing, AI etc.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Thursday, June 1, 2023 at 12:38:31 PM UTC-5, Anton Ertl wrote:
> BGB <cr8...@gmail.com> writes:
> >On 5/29/2023 3:36 PM, Scott Lurndal wrote:
> >IMHO, going much past 128 bits likely goes into diminishing returns
> >territory.
> The Cray-1 has 4096-bit vector registers, and some of the other vector
> machines succeeding it used even longer vectors.
> >For practical working sizes for data, 32/64/128 make sense.
> > 8 and 16 bits make sense for storage or for SIMD elements.
> > 256 or 512 are almost "too big to be useful" in most cases.
> If you do some data-parallel processing (where the SIMD stuff shines),
> doubling the SIMD width can (in the best case) halve the time needed
> to process the data.
> >Progressively doubling the size of the registers doesn't seem to make
> >sense from a cost POV.
> You double only the data and don't need to double rename resources
> etc. (IIRC Zen4 splits an AVX-512 instruction into two 256-bit parts
> that have independently renamed 256-bit registers, though).
> >Say, for example, I would imagine that 32x 512-bit registers will cost a
> >fair bit more than 32x 128-bit registers.
> >
> >But, what can one "actually do with them" to justify the additional
> >costs?...
> Encoding,
integer
> decoding,
integer
> encrypting,
integer
> wheather prediction,
large FP
> hydrodynamics,
large FP
> image processing,
mostly integer
now graphics is a mix of short FP and integer
> AI etc.
really short FP--but still searching for exactly what really short FP.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On 6/1/2023 8:56 AM, Scott Lurndal wrote:
> "robf...@gmail.com" <robfi680@gmail.com> writes:
>> On Wednesday, May 31, 2023 at 1:12:39=E2=80=AFPM UTC-4, BGB wrote:
>>> On 5/31/2023 10:22 AM, Stephen Fuld wrote:=20
>>>> On 5/30/2023 10:54 PM, Anton Ertl wrote:=20
>
>>> =20
>>> An ISA with 128-bit GPRs would be the more preferable option, and one=20
>>> could likely use the large registers either for a large address space,=20
>>> or maybe bounds-checked access or capabilities.=20
>>> =20
>>> =20
>>> Say, Array Pointer:=20
>>> ( 63: 0): Address Field=20
>>> ( 83: 64): Array Size (Scaled)=20
>>> (103: 84): Array Lower Bias=20
>>> (108:104): Array Scale / Exponent=20
>>> (111:109): Array RWX Mode=20
>>> (123:112): Array Element Tag=20
>>> (127:124): Top-Level Tag (Say, 0011 for Array)=20
>
> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
>

Yeah.

This was not meant to reflect the CHERI layout, but would serve a
functionally similar purpose.

I already have something similar in my ISA, though its scope is more
limited (mostly just used for bounds checks).

CHERI is pros/cons, but some parts seem like good ideas (and ISA
enforced bounds checking is a pretty nifty debugging feature, in any case).

In my case, the bounding scheme operates in a slightly different way.

Looking stuff up:
CHERI "Low Fat" 64-bit
(45: 0): Address
(51:46): Base
(57:52): Top
(63:58): Exponent

CHERI-128:
( 63: 0): Address
( 66: 64): BaseExp
( 83: 67): Base
( 86: 84): TopExp
(104: 87): Top
( 105): Sealed
( 106): Top-Increment
(111:107): -
(127:112): Permissions

And, my case:
BJX2, Bounds-Checked, 64-bit
(47: 0): Address
(50:48): Array Size
(55:51): Exponent (Log2)
(59:56): Bias
(63:60): Tag (0011)

BJX2, Bounds-Checked, 128-bit
( 47: 0): Address (Low, Addr(47:0) )
( 59: 48): Size
( 63: 60): Tag (0011)
(111: 64): Address (High, Addr(95:48) )
(123:112): Bias
(127:124): Exponent (Log4, 0=16B)

The CHERI schemes would be more accurate in these cases.

They seem to work by using the Exponent, Base, and Top, to unpack into a
pair of upper and lower bounds, eg:
LowBound = { Addr[max:exp+width], Base, zeroes[exp-1:0] };
TopBound = { Addr[max:exp+width], Top, zeroes[exp-1:0] };

And then evaluating:
LowBound <= Addr < TopBound

The BJX2 scheme had instead encoded a relative upper bound, and a Bias
which encodes the aligned distance between current address and the Lower
Bound.

In the 64 bit format, the array size is encoded with a hidden bit (like
in a floating point formats). The current 128-bit formats lack a hidden
bit (so are non-normalized).

Also, very possibly the 96-bit address space is needlessly overkill.

The existing 128-bit format was the older format in this case (partly
related to the Log4 wonk). The use of Log4 seems like a misstep in
retrospect.

So, an operation like LEAT would perform a LEA, and then use this to
figure out how far to adjust the Bias (my scheme needs to account for
carry out of the low-order bits, which would be N/A in the CHERI scheme).

In my case, the bounds-checking operation is performed relative to the
exponent rather than using absolute address comparisons. Mostly because
this is cheaper and "less bad" for timing.

So, in this case, after an address calculation, so long as:
0 <= NewBias < Size

If NewBias is out of range, either trigger a Bounds Fault, or change to
a Trap representation, depending on the operation.

There are pros/cons between the two bounds encoding schemes.
Not entirely sure which is better.
Though, the CHERI scheme does seem to make more intuitive sense.

There is a functional difference between 64 and 128-bit pointers in my case:
64-bit pointers are unchecked by default;
128-bit pointers are assumed bounds-checked if the tag says so.

In the former case, it is needed to invoke the bounds check manually,
whereas the latter will just assume the use of bounds checking.

Had considered a possible variant that uses a 128-bit pointer with
48-bit address (located in the same part of the address space as the
64-bit pointers)

Could then afford to put access-rights metadata in the pointer.

Say, for example:
( 47: 0): Address (Low)
( 59: 48): Object/Array Type
( 63: 60): Tag
( 83: 64): Bias
(103: 84): Size
(108:104): Exponent
(111:109): RWX Mask
(127:112): ACLID (Access Control List) (?)

....

In case anyone is wondering, No, the ACL's are not intended as any sort
of "server" feature; rather they are a part of my memory-protection
scheme. Though, whether putting them in pointers "makes sense" (and does
not open a potential security hole) is debatable.

I guess the other factor is whether to try to find some way of taking
registers (and memory) as pointer or non-pointer.

Doing this for registers wouldn't be too hard (there would just now need
to be an extra control register holding the "pointer bit" for all the
other registers).

Memory tagging is the harder problem here...

....

On Thursday, June 1, 2023 at 8:56:55 AM UTC-5, Scott Lurndal wrote:
>
> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
<
If there is one thing I am smart enough to understand::
<
It is that I am not smart enough to grasp capabilities to the extent
needed to architect a capability machine.
<
.............

On 6/1/2023 9:03 PM, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 8:56:55 AM UTC-5, Scott Lurndal wrote:
>>
>> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
> <
> If there is one thing I am smart enough to understand::
> <
> It is that I am not smart enough to grasp capabilities to the extent
> needed to architect a capability machine.
> <
> ............

Is any of us?...

This is why BJX2 is not a capability machine, even if it does "borrow" a
few design ideas...

Admittedly, I have put a more of my "security eggs" in the "page tables
and page-level memory protection" basket.

Well, and throw in some ASLR and similar for good measure...

On Friday, June 2, 2023 at 3:03:56 AM UTC+1, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 8:56:55 AM UTC-5, Scott Lurndal wrote:
> >
> > See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
> <
> If there is one thing I am smart enough to understand::
> It is that I am not smart enough to grasp capabilities to the extent
> needed to architect a capability machine.

my professor at imperial back in (eek!) 1989 explained it
to me, i wish i could remember his name.

* Access Control gives you information about what exists
*and* then also says whether you can (or cannot) use it
* Cambridge Capability doesn't even let you know if the
information exists, let alone allows you to use it.

therefore we may say that Virtual Memory Page tables
are in fact a "Capability" System, but the Page-Table
read/write/execute bits are *NOT* Capabiltiy-compliant
they are Access Control (and frequently described in
actual ISA Ref Manuals as such).

that was back then - i have no idea what they done now.

l.

On Thursday, June 1, 2023 at 4:50:26 AM UTC+3, MitchAlsup wrote:
> On Wednesday, May 31, 2023 at 8:04:47 PM UTC-5, robf...@gmail.com wrote:
> > On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
> > > On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> > > > On 5/30/2023 10:54 PM, Anton Ertl wrote:
> > > >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > > >>> But then how do you propose
> > > >>> handling 128 bit arithmetic (both integer and floating), assuming these
> > > >>> are requirements? ISTM that if you don't use paired registers, then you
> > > >>> have to double the number of register specifiers in each ALU
> > > >>> instruction or do something like Mitch's instruction modifier mechanism
> > > >>> or go to 128 bit registers.
> > > >>
> > > >> 128-bit registers look fine to me. AMD64 has them already (the xmm
> > > >> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> > > >> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> > > >> registers). So you just need to add the instructions that use them
> > > >> for computing with 128-bit values.
> > > >
> > > > Fair enough. I agree with Mitch in that I don't like the separate SIMD
> > > > register approach, preferring VVM, but that would mean 128 bit GPRs,
> > > > which we are not ready for yet. (The key word here is yet. I expect
> > > > they will come.) If 128 bit arithmetic becomes popular, and it is only
> > > > implemented in the SIMD registers, you could end up with something like
> > > > the 68000 with separate data versus address registers. :-(
> > > >
> > > I would personally much rather see a single unified register file, in
> > > any case.
> > >
> > >
> > > An ISA with 128-bit GPRs would be the more preferable option, and one
> > > could likely use the large registers either for a large address space,
> > > or maybe bounds-checked access or capabilities.
> > >
> > >
> > > Say, Array Pointer:
> > > ( 63: 0): Address Field
> > > ( 83: 64): Array Size (Scaled)
> > > (103: 84): Array Lower Bias
> > > (108:104): Array Scale / Exponent
> > > (111:109): Array RWX Mode
> > > (123:112): Array Element Tag
> > > (127:124): Top-Level Tag (Say, 0011 for Array)
> > >
> > > Could still need fine adjustment, potentially 20 bits is overkill for
> > > the size field when combined with an exponent.
> > > Say, if we allow an 8B alignment, this allows an array that is 8MB which
> > > is, most likely, going to be page-aligned.
> > >
> > > If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
> > > were smaller, this would mean more likely needing to pad arrays in many
> > > cases.
> > >
> > >
> > > Main drawback being that, if the program is primarily working with
> > > 32-bit 'int' values, then 128-bit registers would be kind of a waste.
> > >
> > >
> > > It is usually only in edge cases that 128-bit integers really "make
> > > sense", and even then, existing C compilers tend to not support them.
> > >
> > > Like, if on many targets, if one does "__int128", the compiler is like
> > > "Not supported on this target", this is a disincentive to use them, and
> > > means that typically the program will (at most) end up only using half
> > > the register.
> > >
> > >
> > > Though, could have the amusing property if, say, one supports fixnum's,
> > > and the fixnum ends up having a larger value range than C's 'long' and
> > > 'long long' types...
> > >
> > >
> > > Other concerns:
> > > Resource cost would likely be higher, as now supporting superscalar is a
> > > bit more of an ask;
> > > Maximum clock speed would likely be lower;
> > > ...
> > >
> > > Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
> > > superscalar).
> > >
> > >
> > > But, yeah, could work...
> > >
> > >
> > > >
> > > >
> > I think 64-bits for the address field may not be enough for a virtual address. I
> > seem to recall a demand for 100-bit addressing in an alternate reality, but that
> > is probably quite a few years away. I also think it is better to have registers
> > just as a plain bucket. As soon as structure is added the design is stuck with
> > it. A separate tags file associated with registers might be easier to manage.
> >
> > I am not so sure about the slowness of a superscalar. I think it may have more
> > to do with how full the FPGA is, the size and style of the design. I have been
> > able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
> > par with many other FPGA designs. Even if it is a few MHz slower the ability of
> > OoO to hide latency may make it worth it.
> >
> > *****
> > I cannot believe I ignored Cordic for so long, having discovered its beauty.
> <
> Beautiful and slow as crap.
> <
> > Answering my own engineering question, 10-bits max micro-code it is; that
> > should be overkill. It should not take very many, if any micro-code words for
> > basic trig. Previously seven bits were used for Thor2021, but only about a half
> > dozen non-math instructions were micro-coded.
> >
> > Having done some head scratching over cordic and how to calculate the tan,
> > I am thinking of just providing a cordic instruction that takes all three
> > arguments and calculates away, and then leave it up to the programmer to
> > decide on operands and what is being calculated. I get how to calculate sin
> > and cosine via cordic and I think tan finally. Specifying that x, y must be
> > fractions between 0 and 1, and that the angle must be radians between 0
> > and 2 pi.
> >
> > I gather that modern processor do not use Cordic, and use polynomial
> > expansions instead.
> <
> Typical SW can perform tan() in 150± cycles.

How do you know?
From past experience I would guess that you didn't actually measure it, do you?

On Thursday, June 1, 2023 at 8:24:47 PM UTC+3, Anton Ertl wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
> >ARM's scalable vector extension allows implementations to choose
> >any power of two between 128 and 2048 bits. Current extant implementations
> >only support 128 bits so far as I am aware.
> The Fujitsu A64FX supports 512-bit SVE; it was one of the earliest, if
> not the earliest SVE implementation.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

The earliest by far. Fugaku prototype topped Green500 list back in Nov 2019.
I think, the next implementation didn't appear until Dec 2021.

As to extant implementation with width that differs from both 512 and 128,
there is Arm Neoverse-V1 that features 256-bit SVE.
Considering that V1 is at heart of AWS Graviton3, I'd say that it not just extant,
but orders of magnitude more extant than any Arm SOC ever made by Cavium.
Probably at least order of magnitude more extant than SoCs made by ex-Cavium
division of Marvel.
On the other hand, in comparison to Cortex X2 and X3 (128-bit SVE) Neoverse-V1
is indeed not numerous.

"luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>On Friday, June 2, 2023 at 3:03:56=E2=80=AFAM UTC+1, MitchAlsup wrote:
>> On Thursday, June 1, 2023 at 8:56:55=E2=80=AFAM UTC-5, Scott Lurndal wrot=
>e:=20
>> >=20
>> > See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/=20
>> <=20
>> If there is one thing I am smart enough to understand::=20
>> It is that I am not smart enough to grasp capabilities to the extent=20
>> needed to architect a capability machine.=20
>
>my professor at imperial back in (eek!) 1989 explained it
>to me, i wish i could remember his name.
>
>* Access Control gives you information about what exists
> *and* then also says whether you can (or cannot) use it
>* Cambridge Capability doesn't even let you know if the
> information exists, let alone allows you to use it.

The key point about capabilities is that they can only
be created or modified under very constrained conditions;
e.g. new capabilities can only be constructed as a subset
of an existing capability. This requires that capabilities
be 'tagged' in some way to prevent software from corrupting
or updating the capability.

On 6/2/2023 9:57 AM, Scott Lurndal wrote:
> "luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>> On Friday, June 2, 2023 at 3:03:56=E2=80=AFAM UTC+1, MitchAlsup wrote:
>>> On Thursday, June 1, 2023 at 8:56:55=E2=80=AFAM UTC-5, Scott Lurndal wrot=
>> e:=20
>>>> =20
>>>> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/=20
>>> <=20
>>> If there is one thing I am smart enough to understand::=20
>>> It is that I am not smart enough to grasp capabilities to the extent=20
>>> needed to architect a capability machine.=20
>>
>> my professor at imperial back in (eek!) 1989 explained it
>> to me, i wish i could remember his name.
>>
>> * Access Control gives you information about what exists
>> *and* then also says whether you can (or cannot) use it
>> * Cambridge Capability doesn't even let you know if the
>> information exists, let alone allows you to use it.
>
> The key point about capabilities is that they can only
> be created or modified under very constrained conditions;
> e.g. new capabilities can only be constructed as a subset
> of an existing capability. This requires that capabilities
> be 'tagged' in some way to prevent software from corrupting
> or updating the capability.
>

Yes.

This is also where the problems begin...
And also their major weakness if used as a security feature (in place of
more traditional access control).

This is why I had initially thought of only trying to copy the
bounds-checking aspects, and then handle the security aspects via a
different mechanism (access control lists) and putting things at random
addresses within a 96-bit address space.

Though, the latter point turned out to be a problem, as with deep page
tables, randomizing the address can make for a "very bad" level of
overhead (but mostly a non-issue for shallow tables). Only workarounds I
have are, arguably, not ideal.

Will at least claim they work in my use-cases though (which are not in
areas that are traditionally all that concerned with security). And, my
stuff is admittedly "not very secure", but does have an "implicit air
gap" for sake of not having a network stack... (network support being
"TODO, eventually").

On 6/1/2023 12:46 PM, MitchAlsup wrote:
> On Thursday, June 1, 2023 at 12:38:31 PM UTC-5, Anton Ertl wrote:
>> BGB <cr8...@gmail.com> writes:
>>> On 5/29/2023 3:36 PM, Scott Lurndal wrote:
>>> IMHO, going much past 128 bits likely goes into diminishing returns
>>> territory.
>> The Cray-1 has 4096-bit vector registers, and some of the other vector
>> machines succeeding it used even longer vectors.
>>> For practical working sizes for data, 32/64/128 make sense.
>>> 8 and 16 bits make sense for storage or for SIMD elements.
>>> 256 or 512 are almost "too big to be useful" in most cases.
>> If you do some data-parallel processing (where the SIMD stuff shines),
>> doubling the SIMD width can (in the best case) halve the time needed
>> to process the data.

If your data is big enough to make effective use of the larger SIMD
registers, and there is a good way to express them in the language...

This is where "SIMD intrinsics" in compilers tend to hit a road bump, as
there is typically no real way to deal with variability in register size
of feature-set short of rewriting the code for each combination.

I guess large vectors could be more useful if the language supported
"abstract large vector" and "tensor" types and operators. Where, say, if
one specifies a tensor type and operator, they don't need to care how
wide the underlying SIMD unit is.

But, then again, since it is pretty hit-or-miss whether '__int128' will
work on a given target, one can't hold out much hope...

>>> Progressively doubling the size of the registers doesn't seem to make
>>> sense from a cost POV.
>> You double only the data and don't need to double rename resources
>> etc. (IIRC Zen4 splits an AVX-512 instruction into two 256-bit parts
>> that have independently renamed 256-bit registers, though).

Some stuff still moves quickly it seems...

It was only a few years ago that I got a Zen+, which seemingly still
uses 128-bit internally (but sorta fake it for 256-bit AVX ops).

>>> Say, for example, I would imagine that 32x 512-bit registers will cost a
>>> fair bit more than 32x 128-bit registers.
>>>
>>> But, what can one "actually do with them" to justify the additional
>>> costs?...
>> Encoding,
> integer
>> decoding,
> integer
>> encrypting,
> integer
>> wheather prediction,
> large FP
>> hydrodynamics,
> large FP
>> image processing,
> mostly integer
> now graphics is a mix of short FP and integer
>> AI etc.
> really short FP--but still searching for exactly what really short FP.

Yeah.

For image processing:
RGB555 and RGBA8888 work well for storage, but aren't ideal for processing.

For image processing, in many cases, one often needs either packed Int16
or Binary16 for the intermediate values.

Similarly, for the NNs I had used (mostly for image processing tasks and
similar thus far), Binary16 works OK for processing.

Some people use BF16 (S.E8.F7), but I mostly prefer Binary16 instead. I
suspect most of the appeal of BF16 is that it is easier to pull off
efficiently on machines which have Binary32 support but not Binary16.

One can try using 8-bit formats, such as S.E4.F3 or S.E3.F4, as a
processing format, but these are a little limited even for NNs (but,
they can still be useful as storage formats).

Say, once the value goes through an activation function, the precision
requirements drop significantly (just they matter a little more for the
"multiply and accumulate" stage).

A cheap activation function can also help (such as a crude approximation
of a square-root or signed square root of similar).

Well, along with:
y=(y<0)?0:y;
y=(y<0.5)?0.0:1.0;
...

Using intermediate forms, like:
S.E5.F6 or S.E5.F4
Can still be effective though.

>> - anton
>> --
>> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
>> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

BGB <cr88192@gmail.com> writes:
>On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>> "luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>>> On Friday, June 2, 2023 at 3:03:56=E2=80=AFAM UTC+1, MitchAlsup wrote:
>>>> On Thursday, June 1, 2023 at 8:56:55=E2=80=AFAM UTC-5, Scott Lurndal wrot=
>>> e:=20
>>>>> =20
>>>>> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/=20
>>>> <=20
>>>> If there is one thing I am smart enough to understand::=20
>>>> It is that I am not smart enough to grasp capabilities to the extent=20
>>>> needed to architect a capability machine.=20
>>>
>>> my professor at imperial back in (eek!) 1989 explained it
>>> to me, i wish i could remember his name.
>>>
>>> * Access Control gives you information about what exists
>>> *and* then also says whether you can (or cannot) use it
>>> * Cambridge Capability doesn't even let you know if the
>>> information exists, let alone allows you to use it.
>>
>> The key point about capabilities is that they can only
>> be created or modified under very constrained conditions;
>> e.g. new capabilities can only be constructed as a subset
>> of an existing capability. This requires that capabilities
>> be 'tagged' in some way to prevent software from corrupting
>> or updating the capability.
>>
>
>Yes.
>
>This is also where the problems begin...

Please enumerate the problems as you see them.

>And also their major weakness if used as a security feature (in place of
>more traditional access control).

Again, why do you believe this to be a major weakness, and what
"traditional access control" mechanism do you believe is superior?

Note that the Unisys clearpath libra systems are still completely
capability based and security is considered superior to the more
modern non-capability based systems (some extremely small part of which
is due to obscurity, granted). The stack is hardware managed, so no
buffer overflow can target the return instruction address; buffer overflows
are impossible in any case, ROP attacks are impossible, etc.

The only viable attack on those systems was discovered fifty years
ago (and fixed shortly thereafter) and involved copying a program to
tape, loading it on an IBM mainframe, patching it to mark it a compiler[*],
then reloading it on the Burroughs machines. Was even written up in
CACM, IIRC.

[*] Compilers were the only way to generate executable codefiles, and
security restrictions were enforced by the compilers.

On Friday, June 2, 2023 at 5:03:06 AM UTC-5, Michael S wrote:
> On Thursday, June 1, 2023 at 4:50:26 AM UTC+3, MitchAlsup wrote:
> > On Wednesday, May 31, 2023 at 8:04:47 PM UTC-5, robf...@gmail.com wrote:
> > > On Wednesday, May 31, 2023 at 1:12:39 PM UTC-4, BGB wrote:
> > > > On 5/31/2023 10:22 AM, Stephen Fuld wrote:
> > > > > On 5/30/2023 10:54 PM, Anton Ertl wrote:
> > > > >> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:
> > > > >>> But then how do you propose
> > > > >>> handling 128 bit arithmetic (both integer and floating), assuming these
> > > > >>> are requirements? ISTM that if you don't use paired registers, then you
> > > > >>> have to double the number of register specifiers in each ALU
> > > > >>> instruction or do something like Mitch's instruction modifier mechanism
> > > > >>> or go to 128 bit registers.
> > > > >>
> > > > >> 128-bit registers look fine to me. AMD64 has them already (the xmm
> > > > >> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> > > > >> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> > > > >> registers). So you just need to add the instructions that use them
> > > > >> for computing with 128-bit values.
> > > > >
> > > > > Fair enough. I agree with Mitch in that I don't like the separate SIMD
> > > > > register approach, preferring VVM, but that would mean 128 bit GPRs,
> > > > > which we are not ready for yet. (The key word here is yet. I expect
> > > > > they will come.) If 128 bit arithmetic becomes popular, and it is only
> > > > > implemented in the SIMD registers, you could end up with something like
> > > > > the 68000 with separate data versus address registers. :-(
> > > > >
> > > > I would personally much rather see a single unified register file, in
> > > > any case.
> > > >
> > > >
> > > > An ISA with 128-bit GPRs would be the more preferable option, and one
> > > > could likely use the large registers either for a large address space,
> > > > or maybe bounds-checked access or capabilities.
> > > >
> > > >
> > > > Say, Array Pointer:
> > > > ( 63: 0): Address Field
> > > > ( 83: 64): Array Size (Scaled)
> > > > (103: 84): Array Lower Bias
> > > > (108:104): Array Scale / Exponent
> > > > (111:109): Array RWX Mode
> > > > (123:112): Array Element Tag
> > > > (127:124): Top-Level Tag (Say, 0011 for Array)
> > > >
> > > > Could still need fine adjustment, potentially 20 bits is overkill for
> > > > the size field when combined with an exponent.
> > > > Say, if we allow an 8B alignment, this allows an array that is 8MB which
> > > > is, most likely, going to be page-aligned.
> > > >
> > > > If we assume a 4K alignment, this allows up to 4GB. OTOH, if the field
> > > > were smaller, this would mean more likely needing to pad arrays in many
> > > > cases.
> > > >
> > > >
> > > > Main drawback being that, if the program is primarily working with
> > > > 32-bit 'int' values, then 128-bit registers would be kind of a waste.
> > > >
> > > >
> > > > It is usually only in edge cases that 128-bit integers really "make
> > > > sense", and even then, existing C compilers tend to not support them.
> > > >
> > > > Like, if on many targets, if one does "__int128", the compiler is like
> > > > "Not supported on this target", this is a disincentive to use them, and
> > > > means that typically the program will (at most) end up only using half
> > > > the register.
> > > >
> > > >
> > > > Though, could have the amusing property if, say, one supports fixnum's,
> > > > and the fixnum ends up having a larger value range than C's 'long' and
> > > > 'long long' types...
> > > >
> > > >
> > > > Other concerns:
> > > > Resource cost would likely be higher, as now supporting superscalar is a
> > > > bit more of an ask;
> > > > Maximum clock speed would likely be lower;
> > > > ...
> > > >
> > > > Could be OK for a 1-wide scalar machine though (or maybe a future 2-wide
> > > > superscalar).
> > > >
> > > >
> > > > But, yeah, could work...
> > > >
> > > >
> > > > >
> > > > >
> > > I think 64-bits for the address field may not be enough for a virtual address. I
> > > seem to recall a demand for 100-bit addressing in an alternate reality, but that
> > > is probably quite a few years away. I also think it is better to have registers
> > > just as a plain bucket. As soon as structure is added the design is stuck with
> > > it. A separate tags file associated with registers might be easier to manage.
> > >
> > > I am not so sure about the slowness of a superscalar. I think it may have more
> > > to do with how full the FPGA is, the size and style of the design. I have been
> > > able to hit close to 50 MHz timing according to the tools. I think 50 MHz is on
> > > par with many other FPGA designs. Even if it is a few MHz slower the ability of
> > > OoO to hide latency may make it worth it.
> > >
> > > *****
> > > I cannot believe I ignored Cordic for so long, having discovered its beauty.
> > <
> > Beautiful and slow as crap.
> > <
> > > Answering my own engineering question, 10-bits max micro-code it is; that
> > > should be overkill. It should not take very many, if any micro-code words for
> > > basic trig. Previously seven bits were used for Thor2021, but only about a half
> > > dozen non-math instructions were micro-coded.
> > >
> > > Having done some head scratching over cordic and how to calculate the tan,
> > > I am thinking of just providing a cordic instruction that takes all three
> > > arguments and calculates away, and then leave it up to the programmer to
> > > decide on operands and what is being calculated. I get how to calculate sin
> > > and cosine via cordic and I think tan finally. Specifying that x, y must be
> > > fractions between 0 and 1, and that the angle must be radians between 0
> > > and 2 pi.
> > >
> > > I gather that modern processor do not use Cordic, and use polynomial
> > > expansions instead.
> > <
> > Typical SW can perform tan() in 150± cycles.
> How do you know?
> From past experience I would guess that you didn't actually measure it, do you?
<
https://hal.inria.fr/inria-00070636/document
and
http://www.cl.cam.ac.uk/~jrh13/slides/gelato-25may05/slides.pdf
<
the later using 2 FMACs simultaneously.
But there is scant little data on it.

On 6/2/2023 12:14 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>>> "luke.l...@gmail.com" <luke.leighton@gmail.com> writes:
>>>> On Friday, June 2, 2023 at 3:03:56=E2=80=AFAM UTC+1, MitchAlsup wrote:
>>>>> On Thursday, June 1, 2023 at 8:56:55=E2=80=AFAM UTC-5, Scott Lurndal wrot=
>>>> e:=20
>>>>>> =20
>>>>>> See https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/=20
>>>>> <=20
>>>>> If there is one thing I am smart enough to understand::=20
>>>>> It is that I am not smart enough to grasp capabilities to the extent=20
>>>>> needed to architect a capability machine.=20
>>>>
>>>> my professor at imperial back in (eek!) 1989 explained it
>>>> to me, i wish i could remember his name.
>>>>
>>>> * Access Control gives you information about what exists
>>>> *and* then also says whether you can (or cannot) use it
>>>> * Cambridge Capability doesn't even let you know if the
>>>> information exists, let alone allows you to use it.
>>>
>>> The key point about capabilities is that they can only
>>> be created or modified under very constrained conditions;
>>> e.g. new capabilities can only be constructed as a subset
>>> of an existing capability. This requires that capabilities
>>> be 'tagged' in some way to prevent software from corrupting
>>> or updating the capability.
>>>
>>
>> Yes.
>>
>> This is also where the problems begin...
>
> Please enumerate the problems as you see them.
>

The need for tagged memory... Well, and/or opaque handles with a
separate address space for the capabilities; take a pick which is worse.

The need for a bunch of new instructions specific to pointer management
(as opposed to using generic) integer instructions for everything.

No deal-breakers per se.

Though, admittedly, the existing bounds-checking scheme does create an
incentive to add more specialized pointer ops, so may still end up with
these in any case.

>> And also their major weakness if used as a security feature (in place of
>> more traditional access control).
>
> Again, why do you believe this to be a major weakness, and what
> "traditional access control" mechanism do you believe is superior?
>

If you can find a way to forge capabilities, or steal capabilities from
elsewhere, this shoots a big hole in the security model. Maintaining
security without also adding significant hinderances to software
development seems like a bit of a balancing act.

Not so much a fundamental weakness of capability model itself, but
rather an uncertainty about the activities of "mere mortal" programmers
(the incentive being far more often to leave a big gaping hole in the
name of convenience or experience than to "do the right thing" in a
security sense).

But, as noted, my thinking was more that one assigns access control
lists to each memory allocation, and "keys" to each thread or
(temporarily) on a per-module basis.

Say, a certain DLL is allowed to access a certain ACL, but no one else,
with the OS moderating control-flow into and out-of this location (but,
then one needs mutual non-executability/etc in terms of the code
regions, say to prevent someone from trying to hack-in callbacks to
sidestep the flow-control; and all this adds about a potential attack
surface if things aren't set up correctly; back to the whole
"expedience" thing). So, per-thread ACL keys is more likely the more
practical model.

As-is, I had gone per-thread, with (effectively) some APIs working as C
wrappers for COM style objects, with the COM-style objects effectively
initiating a task-switch and RPC into another thread (which operates as
an event-pump for that API).

Say, for example, TKGDI might have Read-Only or Read-Write access to
parts of the program's address space (RW to Heap, RO to most other
areas, No Execute). Program has no direct access to TKGDI's data.

Plan was to move TKRA-GL over to a similar model (eventually, but OpenGL
is a slightly more complex API, and work needs to be split with the
"client side" to avoid it becoming dead-slow).

My model is still not exactly perfect though.

Addr96 also complicates stuff, so I was left considering a scheme to
"compact" Addr96 access down to a 64-bit pointer format (by adding a
level of indirection, treating the pointer as essentially a
Handle+Offset pair, with the "actual" 128-bit base pointer held in a
separate kernel-managed table).

This can allow a "slightly more workable" model for temporarily sharing
objects between tasks (since they could then look more like local pointers).

This would almost work in a vaguely similar way to how "far pointers"
were seemingly intended to be used in x86 protected mode, just with an
internal "shared pointer table" taking over the role of the GDT and LDT,
likely existing in semi-disjoint address space from the main 48-bit
virtual address space.

> Note that the Unisys clearpath libra systems are still completely
> capability based and security is considered superior to the more
> modern non-capability based systems (some extremely small part of which
> is due to obscurity, granted). The stack is hardware managed, so no
> buffer overflow can target the return instruction address; buffer overflows
> are impossible in any case, ROP attacks are impossible, etc.
>

Yeah, eliminating buffer overflows was a motivation for borrowing "some"
ideas from CHERI and similar, even if my scheme isn't exactly 1:1.

It is also useful for debugging, as now going out of bounds in an array
can be an immediate CPU fault.

> The only viable attack on those systems was discovered fifty years
> ago (and fixed shortly thereafter) and involved copying a program to
> tape, loading it on an IBM mainframe, patching it to mark it a compiler[*],
> then reloading it on the Burroughs machines. Was even written up in
> CACM, IIRC.
>
> [*] Compilers were the only way to generate executable codefiles, and
> security restrictions were enforced by the compilers.

OK.

I was hoping for a model that still holds in the face of untrusted
binary code.

But, this is a bit of an ask...
What I have now still falls well short.

Anton Ertl wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> But then how do you propose
>> handling 128 bit arithmetic (both integer and floating), assuming these
>> are requirements? ISTM that if you don't use paired registers, then you
>> have to double the number of register specifiers in each ALU
>> instruction or do something like Mitch's instruction modifier mechanism
>> or go to 128 bit registers.
>
> 128-bit registers look fine to me. AMD64 has them already (the xmm
> registers), ARMv8-A has them already (and I think ARMv7-A, too;
> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
> registers). So you just need to add the instructions that use them
> for computing with 128-bit values.

This is pretty obviously going to be the main path for adding fp128 to
x64, particularly since you can emulate it now by simply storing the
fp128 bit pattern in an SSE register (or a pair of them in AVX etc), use
the integer load/store operations and trap to an emulator for
FADD128/FSUB128/FMUL128/FMAC128/FDIV128 etc.

Terje

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

Stephen Fuld wrote:
> On 5/30/2023 10:54 PM, Anton Ertl wrote:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> But then how do you propose
>>> handling 128 bit arithmetic (both integer and floating), assuming these
>>> are requirements?  ISTM that if you don't use paired registers, then you
>>>   have to double the number of register specifiers in each ALU
>>> instruction or do something like Mitch's instruction modifier mechanism
>>> or go to 128 bit registers.
>>
>> 128-bit registers look fine to me.  AMD64 has them already (the xmm
>> registers), ARMv8-A has them already (and I think ARMv7-A, too;
>> ARMv9-A is an extension of ARMv8.5-A, and so also supports these
>> registers).  So you just need to add the instructions that use them
>> for computing with 128-bit values.
>
> Fair enough.  I agree with Mitch in that I don't like the separate SIMD
> register approach, preferring VVM, but that would mean 128 bit GPRs,
> which we are not ready for yet. (The key word here is yet.  I expect
> they will come.)  If 128 bit arithmetic becomes popular, and it is only
> implemented in the SIMD registers, you could end up with something like
> the 68000 with separate data versus address registers.  :-(

I would guess that for a large percentage of the "real work" any given
PC is doing, it is using just such a model, with all the core library
routines (graphics/video/crypto/etc) implemented in SIMD, where the
integer regs are mostly used for addressing and loop book keeping.

Terje

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

BGB <cr88192@gmail.com> writes:
>On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:

>>
>> Again, why do you believe this to be a major weakness, and what
>> "traditional access control" mechanism do you believe is superior?
>>
>
>If you can find a way to forge capabilities, or steal capabilities from
>elsewhere, this shoots a big hole in the security model.

So how is that any different from any other security model?

The idea is to make the security footprint as small as possible,
and capabilities are the ideal there, and the corresponding hardware
is easier to make secure.

> Maintaining
>security without also adding significant hinderances to software
>development seems like a bit of a balancing act.

The compilers handle everything. There is no 'significant hindrance
to software development'.

>
>Not so much a fundamental weakness of capability model itself, but
>rather an uncertainty about the activities of "mere mortal" programmers
>(the incentive being far more often to leave a big gaping hole in the
>name of convenience or experience than to "do the right thing" in a
>security sense).

Programmers don't even _know_ (or care) that capabilities are in use. Except
for the very very small percentage that write bare-metal software or
compilers. And that's a very very small percentage of programmers.

>
>Say, a certain DLL is allowed to access a certain ACL, but no one else,
>with the OS moderating control-flow into and out-of this location (but,

DLL? You're still stuck in windows land. In any case, your system will
be far more complex than a capability system, and correspondingly easier
to abuse or bypass. How, exactly, does an operating system 'moderate'
control flow between the application and the DLL?

On 6/2/2023 12:09 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>
>>>
>>> Again, why do you believe this to be a major weakness, and what
>>> "traditional access control" mechanism do you believe is superior?
>>>
>>
>> If you can find a way to forge capabilities, or steal capabilities from
>> elsewhere, this shoots a big hole in the security model.
>
> So how is that any different from any other security model?
>
> The idea is to make the security footprint as small as possible,
> and capabilities are the ideal there, and the corresponding hardware
> is easier to make secure.
>
>
>> Maintaining
>> security without also adding significant hinderances to software
>> development seems like a bit of a balancing act.
>
> The compilers handle everything. There is no 'significant hindrance
> to software development'.
>
>>
>> Not so much a fundamental weakness of capability model itself, but
>> rather an uncertainty about the activities of "mere mortal" programmers
>> (the incentive being far more often to leave a big gaping hole in the
>> name of convenience or experience than to "do the right thing" in a
>> security sense).
>
> Programmers don't even _know_ (or care) that capabilities are in use. Except
> for the very very small percentage that write bare-metal software or
> compilers. And that's a very very small percentage of programmers.

I don't think that is true, at least for C programmers. Some of the
things that are perfectly fine as far as the language is concerned are a
no no for capabilities architectures. That is why C on the
Burroughs/Unisys A series has to be sand boxed.

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

On Friday, June 2, 2023 at 2:09:52 PM UTC-5, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 6/2/2023 12:14 PM, Scott Lurndal wrote:
> >> BGB <cr8...@gmail.com> writes:
> >>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>
> >>
> >> Again, why do you believe this to be a major weakness, and what
> >> "traditional access control" mechanism do you believe is superior?
> >>
> >
> >If you can find a way to forge capabilities, or steal capabilities from
> >elsewhere, this shoots a big hole in the security model.
<
> So how is that any different from any other security model?
>
> The idea is to make the security footprint as small as possible,
> and capabilities are the ideal there, and the corresponding hardware
> is easier to make secure.
<
But harder to make fficient.
<
> > Maintaining
> >security without also adding significant hinderances to software
> >development seems like a bit of a balancing act.
<
> The compilers handle everything. There is no 'significant hindrance
> to software development'.
<
char *p[] = &array[i][j];
<
> >
> >Not so much a fundamental weakness of capability model itself, but
> >rather an uncertainty about the activities of "mere mortal" programmers
> >(the incentive being far more often to leave a big gaping hole in the
> >name of convenience or experience than to "do the right thing" in a
> >security sense).
<
> Programmers don't even _know_ (or care) that capabilities are in use. Except
> for the very very small percentage that write bare-metal software or
> compilers. And that's a very very small percentage of programmers.
> >
> >Say, a certain DLL is allowed to access a certain ACL, but no one else,
> >with the OS moderating control-flow into and out-of this location (but,
<
> DLL? You're still stuck in windows land. In any case, your system will
> be far more complex than a capability system, and correspondingly easier
> to abuse or bypass. How, exactly, does an operating system 'moderate'
> control flow between the application and the DLL?
<
Trampolines ?!?

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>On 6/2/2023 12:09 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>>
>>>>
>>>> Again, why do you believe this to be a major weakness, and what
>>>> "traditional access control" mechanism do you believe is superior?
>>>>
>>>
>>> If you can find a way to forge capabilities, or steal capabilities from
>>> elsewhere, this shoots a big hole in the security model.
>>
>> So how is that any different from any other security model?
>>
>> The idea is to make the security footprint as small as possible,
>> and capabilities are the ideal there, and the corresponding hardware
>> is easier to make secure.
>>
>>
>>> Maintaining
>>> security without also adding significant hinderances to software
>>> development seems like a bit of a balancing act.
>>
>> The compilers handle everything. There is no 'significant hindrance
>> to software development'.
>>
>>>
>>> Not so much a fundamental weakness of capability model itself, but
>>> rather an uncertainty about the activities of "mere mortal" programmers
>>> (the incentive being far more often to leave a big gaping hole in the
>>> name of convenience or experience than to "do the right thing" in a
>>> security sense).
>>
>> Programmers don't even _know_ (or care) that capabilities are in use. Except
>> for the very very small percentage that write bare-metal software or
>> compilers. And that's a very very small percentage of programmers.
>
>I don't think that is true, at least for C programmers. Some of the
>things that are perfectly fine as far as the language is concerned are a
>no no for capabilities architectures. That is why C on the
>Burroughs/Unisys A series has to be sand boxed.

Indeed, C is not designed for a stack archicture that was designed a
decade before C. IIRC, Unisys just give a large data region (described
by a capability) to the C runtime and let the C runtime deal with
translating between native MCP calls and C runtime functionality.

You say 'sandboxed', and that's a good term - within the sandbox
anything goes, but it can't escape the underlying capability
describing the C program address space.

That isn't a problem for CHERI so long as the compilers are
aware of the architectural requirements.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Friday, June 2, 2023 at 2:09:52=E2=80=AFPM UTC-5, Scott Lurndal wrote:
>> BGB <cr8...@gmail.com> writes:=20
>> >On 6/2/2023 12:14 PM, Scott Lurndal wrote:=20
>> >> BGB <cr8...@gmail.com> writes:=20
>> >>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:=20
>>=20
>> >>=20
>> >> Again, why do you believe this to be a major weakness, and what=20
>> >> "traditional access control" mechanism do you believe is superior?=20
>> >>=20
>> >=20
>> >If you can find a way to forge capabilities, or steal capabilities from=
>=20
>> >elsewhere, this shoots a big hole in the security model.
><
>> So how is that any different from any other security model?=20
>>=20
>> The idea is to make the security footprint as small as possible,=20
>> and capabilities are the ideal there, and the corresponding hardware=20
>> is easier to make secure.
><
>But harder to make fficient.

Harder, but not impossible.

><
>> > Maintaining=20
>> >security without also adding significant hinderances to software=20
>> >development seems like a bit of a balancing act.
><
>> The compilers handle everything. There is no 'significant hindrance=20
>> to software development'.
><
> char *p[] =3D &array[i][j];

The compiler can, in CHERI, create a sub-capability for the target region,
which has a fixed size in this case if I recall correctly. Implementations
by a processor vendor would likely differ from pure CHERI.

>> DLL? You're still stuck in windows land. In any case, your system will=20
>> be far more complex than a capability system, and correspondingly easier=
>=20
>> to abuse or bypass. How, exactly, does an operating system 'moderate'=20
>> control flow between the application and the DLL?
><
>Trampolines ?!?

Complicated, performance killing potential security hole.

On Friday, June 2, 2023 at 4:20:52 PM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Friday, June 2, 2023 at 2:09:52=E2=80=AFPM UTC-5, Scott Lurndal wrote:
> >> BGB <cr8...@gmail.com> writes:=20
> >> >On 6/2/2023 12:14 PM, Scott Lurndal wrote:=20
> >> >> BGB <cr8...@gmail.com> writes:=20
> >> >>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:=20
> >>=20
> >> >>=20
> >> >> Again, why do you believe this to be a major weakness, and what=20
> >> >> "traditional access control" mechanism do you believe is superior?=20
> >> >>=20
> >> >=20
> >> >If you can find a way to forge capabilities, or steal capabilities from=
> >=20
> >> >elsewhere, this shoots a big hole in the security model.
> ><
> >> So how is that any different from any other security model?=20
> >>=20
> >> The idea is to make the security footprint as small as possible,=20
> >> and capabilities are the ideal there, and the corresponding hardware=20
> >> is easier to make secure.
> ><
> >But harder to make fficient.
> Harder, but not impossible.
>
> ><
> >> > Maintaining=20
> >> >security without also adding significant hinderances to software=20
> >> >development seems like a bit of a balancing act.
> ><
> >> The compilers handle everything. There is no 'significant hindrance=20
> >> to software development'.
> ><
> > char *p[] =3D &array[i][j];
>
> The compiler can, in CHERI, create a sub-capability for the target region,
> which has a fixed size in this case if I recall correctly. Implementations
> by a processor vendor would likely differ from pure CHERI.
>
>
> >> DLL? You're still stuck in windows land. In any case, your system will=20
> >> be far more complex than a capability system, and correspondingly easier=
> >=20
> >> to abuse or bypass. How, exactly, does an operating system 'moderate'=20
> >> control flow between the application and the DLL?
> ><
> >Trampolines ?!?
> Complicated, performance killing potential security hole.
<
GOT and PLT kill performance ??
<
how else do you perform dynamic linking ??
<
{Hint:: My 66000 only needs GOT and not PLT}.

On 6/2/2023 2:09 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>
>>>
>>> Again, why do you believe this to be a major weakness, and what
>>> "traditional access control" mechanism do you believe is superior?
>>>
>>
>> If you can find a way to forge capabilities, or steal capabilities from
>> elsewhere, this shoots a big hole in the security model.
>
> So how is that any different from any other security model?
>
> The idea is to make the security footprint as small as possible,
> and capabilities are the ideal there, and the corresponding hardware
> is easier to make secure.
>

But, not entirely transparent to "ye olde C".

At least if one accepts all the various ways people like to abuse the
language as at least "semi valid".

>
>> Maintaining
>> security without also adding significant hinderances to software
>> development seems like a bit of a balancing act.
>
> The compilers handle everything. There is no 'significant hindrance
> to software development'.
>

If your language looks like Java or C# or similar.

Or, one is happy to use a subset of C that doesn't allow "abusing"
pointers and type-casts in various ways, or makes various other "non
portable" assumptions.

Admittedly, a lot of this also runs afoul of my bounds-checking scheme.

And also a lot of stuff that is "undefined behavior" as well.

But, if someone tries to compile code and the compiler is like "error:
that aint gonna fly here", they are liable to blame the architecture
rather than fix the code.

OTOH, if it is opt-in, people are more likely to know what they are
getting into (and not enable the option unless they intend to go and fix
their code to clean up any exceptions that may result).

Granted, on any current implementation, it is likely that "breaking"
capabilities will still leave one with the protections offered by the
standard memory protection schemes.

So, one has bounds checking, which is the main practical advantage, and
the "non forgeable" aspect, which is needed for the formal model (eg:
"actually being capabilities"), but likely of secondary importance in
practice (and the one that adds some of the "harder" issues).

>>
>> Not so much a fundamental weakness of capability model itself, but
>> rather an uncertainty about the activities of "mere mortal" programmers
>> (the incentive being far more often to leave a big gaping hole in the
>> name of convenience or experience than to "do the right thing" in a
>> security sense).
>
> Programmers don't even _know_ (or care) that capabilities are in use. Except
> for the very very small percentage that write bare-metal software or
> compilers. And that's a very very small percentage of programmers.
>

Possibly.

Yes, if one writes reasonably type-safe and standards-compliant code, it
is less of an issue.

How easily one can implement various parts of the C library, without
running afoul of things, is also a factor (and the main sorts of areas
where "shortcuts" are a risk).

>
>>
>> Say, a certain DLL is allowed to access a certain ACL, but no one else,
>> with the OS moderating control-flow into and out-of this location (but,
>
> DLL? You're still stuck in windows land. In any case, your system will
> be far more complex than a capability system, and correspondingly easier
> to abuse or bypass. How, exactly, does an operating system 'moderate'
> control flow between the application and the DLL?
>

It is a hybrid model.
But, I am still using a PE/COFF variant, and EXE/DLL file naming
conventions, ...

API conventions are mixed, but uses a Unix style filesystem layout.
So, sort of like a poor knockoff of the Cygwin experience...

As for moderating DLL calls...

Imagine, for a moment, that A does not call B directly, but instead a
thunk is used that effectively performs a system call, which then
performs an implicit "partial task switch", and then invokes a call to
the exported function via a sort of event-dispatcher-loop (whose job is
mostly to handle calls into a given DLL).

In this case, the PE/COFF loader would set up the thunks and dispatcher
tasks as needed.

Kinda sucks, and is slow, but don't yet have a better approach (that
also avoids adding obvious security holes).

So, don't currently plan to go down this particular path for normal DLLs.

Though, at a minimum, would need a system call to reload KRR, and a
mechanism to perform a system call to restore KRR on the return path
(and a way to ensure that no other control flow paths can exist between
the caller and callee, whereas this is easier to enforce if implemented
via an implicit task switch).

Though, generally the caller and callee exist within the same address
space in this model, but this may change.

Have mostly ended up using going with COM-style objects instead though
for this (where the COM-Object method dispatch is also handled via a
similar mechanism, just a specialized system call that is like "Hey,
invoke Method 13 on this object handle with these arguments", and the
system-call mechanism is responsible for performing the appropriate
context switch to the associated handler task).

The objects may then given a C wrapper on the client side.

Well, and also easier to justify some of the seemingly arbitrary
restrictions on the handling of memory references and similar with an
interface resembling COM Objects, than with function pointers or DLL
imports.

As for Addr96 compacting, possibly, say:
6bbb_aaaaaaaa

Maps to "imported object=bbb, offset=aaaaaaaa" mapped to a list of
imported and exported objects (could maybe also make provision for
assigning less address space to smaller objects).

The list would likely need to be tied to the ASID if handled using the
existing TLB mechanism. Giving each task its own ASID would not be ideal
for performance though.

It could make sense to have an ACLID for each object, which would then
be used as the ACLID when accessing the object through the pointer.

This would make provision for exporting an object to an ACL other than
the one assigned to the memory holding the object (say, the ACL of the
object is based on the intended recipient rather than its origin).

The TLB Miss handler would need to do a little extra wonk and remapping
for this though (effectively, it would be first translated by the table,
and then again by the page-table).

....

MitchAlsup <MitchAlsup@aol.com> writes:
>On Friday, June 2, 2023 at 4:20:52=E2=80=AFPM UTC-5, Scott Lurndal wrote:
>> MitchAlsup <Mitch...@aol.com> writes:=20
>> >On Friday, June 2, 2023 at 2:09:52=3DE2=3D80=3DAFPM UTC-5, Scott Lurndal=
> wrote:=20
>> >> BGB <cr8...@gmail.com> writes:=3D20=20
>> >> >On 6/2/2023 12:14 PM, Scott Lurndal wrote:=3D20=20
>> >> >> BGB <cr8...@gmail.com> writes:=3D20=20
>> >> >>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:=3D20=20
>> >>=3D20=20
>> >> >>=3D20=20
>> >> >> Again, why do you believe this to be a major weakness, and what=3D2=
>0=20
>> >> >> "traditional access control" mechanism do you believe is superior?=
>=3D20=20
>> >> >>=3D20=20
>> >> >=3D20=20
>> >> >If you can find a way to forge capabilities, or steal capabilities fr=
>om=3D=20
>> >=3D20
>> >> >elsewhere, this shoots a big hole in the security model.=20
>> ><
>> >> So how is that any different from any other security model?=3D20=20
>> >>=3D20=20
>> >> The idea is to make the security footprint as small as possible,=3D20=
>=20
>> >> and capabilities are the ideal there, and the corresponding hardware=
>=3D20
>> >> is easier to make secure.=20
>> ><=20
>> >But harder to make fficient.
>> Harder, but not impossible.=20
>>=20
>> ><=20
>> >> > Maintaining=3D20=20
>> >> >security without also adding significant hinderances to software=3D20
>> >> >development seems like a bit of a balancing act.=20
>> ><
>> >> The compilers handle everything. There is no 'significant hindrance=3D=
>20=20
>> >> to software development'.=20
>> ><=20
>> > char *p[] =3D3D &array[i][j];=20
>>=20
>> The compiler can, in CHERI, create a sub-capability for the target region=
>,=20
>> which has a fixed size in this case if I recall correctly. Implementation=
>s=20
>> by a processor vendor would likely differ from pure CHERI.=20
>>=20
>>=20
>> >> DLL? You're still stuck in windows land. In any case, your system will=
>=3D20=20
>> >> be far more complex than a capability system, and correspondingly easi=
>er=3D=20
>> >=3D20=20
>> >> to abuse or bypass. How, exactly, does an operating system 'moderate'=
>=3D20
>> >> control flow between the application and the DLL?=20
>> ><=20
>> >Trampolines ?!?
>> Complicated, performance killing potential security hole.
><
>GOT and PLT kill performance ??

They have a non-zero cost. I may have engaged in slight hyperbole.

I'm not sure I'd categorize those as "moderateing" control flow,
however, as there's not much the run-time linker can with the PLT
entries once established.

BGB <cr88192@gmail.com> writes:
>On 6/2/2023 2:09 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 6/2/2023 12:14 PM, Scott Lurndal wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>> On 6/2/2023 9:57 AM, Scott Lurndal wrote:
>>
>>>>
>>>> Again, why do you believe this to be a major weakness, and what
>>>> "traditional access control" mechanism do you believe is superior?
>>>>
>>>
>>> If you can find a way to forge capabilities, or steal capabilities from
>>> elsewhere, this shoots a big hole in the security model.
>>
>> So how is that any different from any other security model?
>>
>> The idea is to make the security footprint as small as possible,
>> and capabilities are the ideal there, and the corresponding hardware
>> is easier to make secure.
>>
>
>But, not entirely transparent to "ye olde C".

The CHERI folks have described language extensions to
adapt C to this type of architecture.

>
>At least if one accepts all the various ways people like to abuse the
>language as at least "semi valid".

They can always devolve to in-line assembler (e.g. for OS/Hypervisors)
to "abuse" the language.

>>
>> The compilers handle everything. There is no 'significant hindrance
>> to software development'.
>>
>
>If your language looks like Java or C# or similar.

Two of the top 5 in use today. Python, C++ and soon
Rust all of which can use capabilites opaque to the
programmer.

>
>Or, one is happy to use a subset of C that doesn't allow "abusing"
>pointers and type-casts in various ways, or makes various other "non
>portable" assumptions.

You mean code for security rather than convenience. I think you
overestimate the amount of language abuse that is tolerated in
production code.

>
>But, if someone tries to compile code and the compiler is like "error:
>that aint gonna fly here", they are liable to blame the architecture
>rather than fix the code.

Come now, every new warning added to gcc or clang is basically
'that ain't gonna fly here' and people aren't blaming anything
but the compiler, if they complain at all, which they don't in
general.