On 1/29/2022 2: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.

Quick skim.

I was aware of these sorts of weaknesses as well.

One idea was to incorporate dynamically-changing random numbers into the
internal hashing in various places in an attempt to defeat some kinds of
exploits which work by exploiting the hash function.

Though, one limiting factor is that this does increase cost and isn't
great for timing.

>>
>> 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.

Yeah.

However, this issue could (also) be reduced by not giving untrusted code
access to a clock-cycle counter (eg, RDTSC or similar).

This likely depends some on how predictable timing is on the target
machine, and the relative speed difference between the running processor
and the available timers.

>>
>> 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 ?

That is a relevant question.

One issue is seems with capabilities (by themselves) as a security
feature is that if one has a way to sidestep them in one small area, it
may become possible to sidestep the capability system as a whole.

As soon as a piece of code can find some way to get access to a "does
whatever" capability (such as by stealing it from something it does have
access to), then they can do whatever from wherever (and then there is a
big gaping security hole).

So, for a capability system, the critical weakness would be the
existence of (or ability to get access to) a "can do anything" capability.

And, admittedly, for my VUGID system, a major weakness would be for
untrusted code to somehow load Zero into the KRR.

This makes things harder, in that in effect one can't be allowed any way
to reload KRR from within user-mode). Though, given VUGID is used in
addition to a more traditional protection ring scheme, bypassing VUGID
would in effect get the code back into a "baseline" usermode.

This is more an issue though for TestKern as I was intending to do a
"single big address space", at which bypassing VUGID could in-theory
give a userland process access to any other userland process.

Though, it could be possible to have an alternate version of usermode
which does not allow disabling VUGID checks.

>>
>>
>> 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 3:51 PM, Ivan Godard wrote:
> 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.
>

FWIW, I am not trying to claim Capabilities are bad or pointless, but
rather that it may be needed to take more of a "kitchen sink" approach.

Both Capabilities and ASLR have weaknesses, but in theory can be used in
combination.

In theory, it is also possible that capabilities could be combined with
VUGID, since while they partly overlap, they also address some different
issues in different ways.

And, granted, "unforgeable reference" is stronger than "hard to guess
due to big numbers and RNG", but tagged memory isn't cheap (it seems
very possible that the mechanisms needed to support tagged memory would
end up more expensive than those needed to support 96 bit virtual
addresses in the L1 caches and TLB).

Though, there is a minor area of concern with the current implementation
that corner cutting used to make the 96-bit addressing more affordable
could themselves create potential attack surfaces (*). One tested
workaround was incorporating an RNG into the L1 caches (but, this wasn't
great for timing).

Yeah, the address stored in the L1's is not so much:
{ otherStuff, addrHi[47:0], addrLo[47:0] } //112 bits
But, more like, say:
{ addrHi[31:16]^addrHi[15:0]^otherStuff,
addrLo[47:32]^addrHi[47:30],
addrLo[31:0] } //64 bits

Where, otherStuff is derived from the current operating mode and XOR'ing
together the bits from the current KRR and similar.

Which leaves a few fairly obvious weaknesses...

(Though, mostly just leaves a small but non-zero possibility of
accessing cache lines, if it is in L1, using an address other than the
one it actually belongs to).

One can be like:
tAddrHi[47:0] = addrHi[47:0] + lastFlushSeed[47:0];
And use tAddrHi instead of addrHi in the above.

But... this isn't free...

Similarly, plain XOR would be ineffective in this case (due to numerical
properties, an XOR would have no effect on the external behavior).

But, this would not fix the possibility of address clashes.

A better implementation would be, granted, to actually store all the
address bits and similar.

> 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.

Yeah.

I had started floating a few ideas for hardware-enforced bounds checks
as well (probably in the context of XMOV instructions), however, they
would still have the limitation of depending on the running program
being "not actively hostile" (there is no way in this case to stop the
program from twiddling the pointer bits in the absence of special tag
bits for registers and memory).

On 1/29/2022 2:16 PM, BGB wrote:
> On 1/29/2022 2: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.
>
> Quick skim.
>
> I was aware of these sorts of weaknesses as well.
>
> One idea was to incorporate dynamically-changing random numbers into the
> internal hashing in various places in an attempt to defeat some kinds of
> exploits which work by exploiting the hash function.
>
> Though, one limiting factor is that this does increase cost and isn't
> great for timing.
>
>
>>>
>>> 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.
>
> Yeah.
>
> However, this issue could (also) be reduced by not giving untrusted code
> access to a clock-cycle counter (eg, RDTSC or similar).
>
> This likely depends some on how predictable timing is on the target
> machine, and the relative speed difference between the running processor
> and the available timers.
>
>
>>>
>>> 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 ?
>
> That is a relevant question.
>
> One issue is seems with capabilities (by themselves) as a security
> feature is that if one has a way to sidestep them in one small area, it
> may become possible to sidestep the capability system as a whole.
>
> As soon as a piece of code can find some way to get access to a "does
> whatever" capability (such as by stealing it from something it does have
> access to), then they can do whatever from wherever (and then there is a
> big gaping security hole).
>

Getting an All cap is the same as getting root privileges; that's all
she said.

An OS built on distributed caps (or on distributed grants for that
matter) doesn't have All caps after boot up. Each subsystem has caps for
the job it does, and asks other subsystems for what it doesn't do
itself. It's a very different model than the usual monolithic OS, and is
I suspect where CHERI has had to do most of its work.

> So, for a capability system, the critical weakness would be the
> existence of (or ability to get access to) a "can do anything" capability.
>
>
> And, admittedly, for my VUGID system, a major weakness would be for
> untrusted code to somehow load Zero into the KRR.
>
> This makes things harder, in that in effect one can't be allowed any way
> to reload KRR from within user-mode). Though, given VUGID is used in
> addition to a more traditional protection ring scheme, bypassing VUGID
> would in effect get the code back into a "baseline" usermode.
>
> This is more an issue though for TestKern as I was intending to do a
> "single big address space", at which bypassing VUGID could in-theory
> give a userland process access to any other userland process.
>
> Though, it could be possible to have an alternate version of usermode
> which does not allow disabling VUGID checks.

MitchAlsup wrote:
>> 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
> <

ASLR is security by obscurity, which we all know is no security at all.
It was originally added to kernel code to make it more difficult for
attackers that are _already inside the kernel_ or _already inside an app_
to write generic attacks. It supposedly made it more likely the attacker
would touch something illegal and crash.

ASLR does what it says on the box, but that is not security.
It's probabilistic detection of intruders already inside the building.

EricP <ThatWouldBeTelling@thevillage.com> writes:
>ASLR is security by obscurity, which we all know is no security at all.

"Security by obscurity" refers to not publishing the security
algorithm you are using in the hopes that the attacker will not be
able to find that out.

There are other things that are not published, such as secret keys and
passwords, which are often used to provide security, which are not
considered "security by obscurity".

Concerning ASLR, the algorithm is published, the randomization
hopefully has cryptographic strength, and it means that the attacker
has to try many addresses on average to get a successful attack. One
problem with that is that there are not that many bits involved in
ASLR, so it's like a short password: it can be brute-forced. However,
many attacks need to deal with several addresses, and if the addresses
are randomized independently, that increases the number of bits.

>It was originally added to kernel code to make it more difficult for
>attackers that are _already inside the kernel_ or _already inside an app_
>to write generic attacks.

That's not the way I would describe it. There is some vulnerability
(typically a buffer overflow) that lets the attacker write stuff into
the attacked program where the programmer of the attacked program had
not intended. And the attacked program then uses this stuff as an
address (or something that's used for constructing an address), and
that address needs to be right for the attacker to achieve his goal.

>It supposedly made it more likely the attacker
>would touch something illegal and crash.
>
>ASLR does what it says on the box, but that is not security.
>It's probabilistic detection of intruders already inside the building.

If the number of attempts the attacker needs to make makes it too
expensive to perform the attack, ASLR has achieved its goal, and is
part of security; it's a defense-in-depth mechanism. But of course it
would be better if the vulnerabilities were fixed for which ASLR
serves as (weak) second line of defense.

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

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> ASLR is security by obscurity, which we all know is no security at all.
>
> "Security by obscurity" refers to not publishing the security
> algorithm you are using in the hopes that the attacker will not be
> able to find that out.

SBO refers to using a lack of knowledge _other than the access key_
to block access to information or things.
The random relocations of ASLR certainly qualify as such.

> There are other things that are not published, such as secret keys and
> passwords, which are often used to provide security, which are not
> considered "security by obscurity".

SBO refers to access other than by the access key.

> Concerning ASLR, the algorithm is published, the randomization
> hopefully has cryptographic strength, and it means that the attacker
> has to try many addresses on average to get a successful attack. One
> problem with that is that there are not that many bits involved in
> ASLR, so it's like a short password: it can be brute-forced. However,
> many attacks need to deal with several addresses, and if the addresses
> are randomized independently, that increases the number of bits.

The question is, can it be accessed without the keys?
Since ASLR does allow access without the key, it is SBO.

>> It was originally added to kernel code to make it more difficult for
>> attackers that are _already inside the kernel_ or _already inside an app_
>> to write generic attacks.
>
> That's not the way I would describe it. There is some vulnerability
> (typically a buffer overflow) that lets the attacker write stuff into
> the attacked program where the programmer of the attacked program had
> not intended. And the attacked program then uses this stuff as an
> address (or something that's used for constructing an address), and
> that address needs to be right for the attacker to achieve his goal.

Each night we move the Picasso's and Monet's to a random different room
in the museum in the hopes that the thieves, having already broken into
the building, will trip an alarm while they search for the paintings.
With enough rooms in the museum, we hope the odds work in our favor.

Might work, except (a) we have to leave an index at the front desk so that
WE can find our own paintings later and thieves can use that index too,
and (b) if the thieves have an alarm disabler allowing them to roam
the museum at will (aka exception handlers).

>> It supposedly made it more likely the attacker
>> would touch something illegal and crash.
>>
>> ASLR does what it says on the box, but that is not security.
>> It's probabilistic detection of intruders already inside the building.
>
> If the number of attempts the attacker needs to make makes it too
> expensive to perform the attack, ASLR has achieved its goal, and is
> part of security; it's a defense-in-depth mechanism. But of course it
> would be better if the vulnerabilities were fixed for which ASLR
> serves as (weak) second line of defense.
>
> - anton

Clearly since both Spectre and Meltdown demos bypassed ASLR trivially,
its not obscure or expensive enough to be useful.

We need to leave pointers so our own code can find those
new locations and attackers can use those pointers
to follow that trail of bread crumbs too.

Also exception handlers effectively disable all the detectors.
Something like Intel RTM atomic transaction user mode exception
handlers make it cheap to disable all the detectors.
(And I'm not suggesting we remove this kind of capability,
just that any security mechanism that depends on it not existing
is kinda screwed.)

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.  :-(

If so, then I'm misremembering the same detail, i.e. the very first
AS400 on Power had a special stepping with 65-bit registers, but by the
time the next Power generation came out, they had figured out how to
handle the AS400 code without this particular HW helper.

Terje

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

On 1/30/2022 6:34 AM, EricP wrote:
> MitchAlsup wrote:
>>> 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
>> <
>
> ASLR is security by obscurity, which we all know is no security at all.
> It was originally added to kernel code to make it more difficult for
> attackers that are _already inside the kernel_ or _already inside an app_
> to write generic attacks. It supposedly made it more likely the attacker
> would touch something illegal and crash.
>
> ASLR does what it says on the box, but that is not security.
> It's probabilistic detection of intruders already inside the building.
>
>

+1

On 1/30/2022 9:27 AM, Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> ASLR is security by obscurity, which we all know is no security at all.
>
> "Security by obscurity" refers to not publishing the security
> algorithm you are using in the hopes that the attacker will not be
> able to find that out.
>
> There are other things that are not published, such as secret keys and
> passwords, which are often used to provide security, which are not
> considered "security by obscurity".
>
> Concerning ASLR, the algorithm is published, the randomization
> hopefully has cryptographic strength, and it means that the attacker
> has to try many addresses on average to get a successful attack. One
> problem with that is that there are not that many bits involved in
> ASLR, so it's like a short password: it can be brute-forced. However,
> many attacks need to deal with several addresses, and if the addresses
> are randomized independently, that increases the number of bits.
>

This is where big address spaces can help...
Bigger address space, more bits for entropy.

Meanwhile, on 32-bit x86, it was most commonly implemented as something
like: load image with an offset that is a randomized multiple of 64
bytes or so relative to the page base.

Then, say, Windows using a 64K logical page size:
This gives theoretically 10 bits or so;
And they only used it by default for DLLs and system-level services;
So, the main EXE is on its own.

On 32-bit systems, VirtualAlloc would proceed linearly, either upward
from low addresses, or downward from high addresses, but with 32-bits
addressing, this is about the most one can do without quickly
fragmenting the address space into an unusable mess.

>> It was originally added to kernel code to make it more difficult for
>> attackers that are _already inside the kernel_ or _already inside an app_
>> to write generic attacks.
>
> That's not the way I would describe it. There is some vulnerability
> (typically a buffer overflow) that lets the attacker write stuff into
> the attacked program where the programmer of the attacked program had
> not intended. And the attacked program then uses this stuff as an
> address (or something that's used for constructing an address), and
> that address needs to be right for the attacker to achieve his goal.
>

Yep.

Buffer overflow is one context.

Another is "theoretically sandboxed" code existing within the same
address space as the "not sandboxed" code hosting the sandbox (assuming
an absense of any other memory protection scheme, *).

If the sandboxed code can guess addresses to things outside the sandbox,
it can break free.

*: My VUGID scheme was initially imagined mostly for these sorts of
scenarios.

However, making it both "strong" and "fully automatic" would pose issues.

It could be applied semi-automatically on a DLL graph, say:
Binary has R+X to its .text section, and R+W to its data/bss;
Binary has R+X to its DLL imports, optional RO or R+W to DLL's data;
It has no access to DLLs it did not import directly.

Things like heap data are harder, as stuff in these areas tends to be
shared freely, and it would create needless hassle if something
"malloc'ed" in one DLL were no-access from another. This needs R+W from
everywhere in a program (or R+W+X on special request).

But, herein lies a few issues...

I have started looking at a few bounds-checked pointer schemes, and have
experimentally added something to the Verilog in my BJX2 core. However,
as-is it would only work with 128-bit pointers (eg: XMOV instructions).

This does involve some kind of "obvious wankery" being added to the AGU,
but thus far timing seems to survive (the AGU now needs to deal with
bounds-checking the accesses, flagging OOB access, and potentially
updating bounds for 'XLEA', which I may need to add for all this to be
'usable').

Enabling it by default on 64-bit pointers would have other issues:
Not enough tag bits for a usable "general purpose" bounds checks;
Could interfere with other tagging schemes (NaN boxing);
...

So, the policy may end up being:
For 64-bit pointers, one may use their own tagging schemes;
For 128-bit pointers, using the scheme specified in the ABI may be required.

It is possible I could allow for "generalized bounds checking", but
doing so would likely require building code with a sub ABI which uses
128-bit pointers as the default.

Current tag-space being (tag bits only):
vvvv-0ttt: Object Tag, t=Type Tag, vvvv=Depends on Type-Tag
vvvv-1ttt: Smaller Tag Value Spaces
xxxx-0000: Bare Pointer (x=Ignored by ABI)
ssss-2sss: Bound Array, s=Size in units of 16B
eddd-3uuu: Double-Bound Array
u=Rel upper bound, d=rel lower bound, e=Element Size (log2-4)/2
4..7: Expanded Fixnum Space (non-pointer)
8..B: Expanded Flonum Space (non-pointer)

The Bound-Array case is up to 4GB.
It works with array indexing, but doesn't work effectively with
'ptr++' or 'ptr--'.

The Double-Bound-Array case depends on granularity.
For 16B, it is up to 64K
For 16K, it us up to 64MB
For 128K, it is up to 1GB.

Idea is that it assumes that both the upper and lower bounds are
relative to the base address at the specified granularity, and that
these bounds are aligned on a 2^(2*e+4) boundary.

For an XLEA, the (Ri<<Sc)>>(2*E+4) would be subtracted from the upper
bound, and added to the lower bound (with low order bits mostly ignored;
though for correct behavior would need to propagate a carry from the
low-order bits when adjusting the bounds).

Though, this design requires effectively using several (albeit smaller)
shifters, which isn't ideal. Would be quantized to a multiple of 2 bits:
0=16B, 1=64B
2=256B, 3=1K
4=4K, 5=16K
6=64K, 7=128K
8..F=Reserved for now.

Operations like 'ptr++' or 'ptr--' would likely require always using
XLEA rather than ADD/SUB. It may also make sense to have an instruction
to set the relative bounds of a pointer.

If this mechanism were to be used "generally", it would likely also
impose constraints on the alignments of allocations made via mmap or malloc.

It could be possible to define much larger bounds if the pointer were
restricted to being within the current quadrant (low 48 bits).

>> It supposedly made it more likely the attacker
>> would touch something illegal and crash.
>>
>> ASLR does what it says on the box, but that is not security.
>> It's probabilistic detection of intruders already inside the building.
>
> If the number of attempts the attacker needs to make makes it too
> expensive to perform the attack, ASLR has achieved its goal, and is
> part of security; it's a defense-in-depth mechanism. But of course it
> would be better if the vulnerabilities were fixed for which ASLR
> serves as (weak) second line of defense.
>

Granted.

This was a major (initial) idea behind the 96-bit address space extension.

Eg, try to make the address space big enough that brute-forcing it
within a timely manner becomes computationally infeasible.

Though, there are still potential weaknesses in other areas (such as
this doesn't necessarily prevent use of localized searches and pattern
matching).

Initially, I didn't expect it to be affordable, but its impact on
overall LUT cost was relatively modest (at least, with hacks to cut the
virtual address stored in the L1 down to 64 bits; and effectively
cutting the TLB associativity in half when dealing with 96-bit lookups).

> - anton

This seems like a good place to insert a potentially thread stealing question:
<
What happens to buffer overflow attacks when there is zero chance of the buffer
overflow harming any control data (such as return address,...) ??
<
The buffer overflows and damages some data the application can read and write,
but the return address, and preserved registers remain unmolested--so control is
not stolen by this means.

On Sunday, January 30, 2022 at 2:34:43 PM UTC-6, BGB wrote:
> On 1/30/2022 9:27 AM, Anton Ertl wrote:

> > That's not the way I would describe it. There is some vulnerability
> > (typically a buffer overflow) that lets the attacker write stuff into
> > the attacked program where the programmer of the attacked program had
> > not intended. And the attacked program then uses this stuff as an
> > address (or something that's used for constructing an address), and
> > that address needs to be right for the attacker to achieve his goal.
> >
> Yep.
>
> Buffer overflow is one context.
>
> Another is "theoretically sandboxed" code existing within the same
> address space as the "not sandboxed" code hosting the sandbox (assuming
> an absense of any other memory protection scheme, *).
>
> If the sandboxed code can guess addresses to things outside the sandbox,
> it can break free.
>
>
> *: My VUGID scheme was initially imagined mostly for these sorts of
> scenarios.
>
>
> However, making it both "strong" and "fully automatic" would pose issues.
>
> It could be applied semi-automatically on a DLL graph, say:
> Binary has R+X to its .text section, and R+W to its data/bss;
<
Why does binary necessarily have R-E access to code (.text) pages?
<
My 66000 architecture gets rid of the need to have R-- access to code pages
{Mainly because ISA eliminates need to read read-only data from the code pages}
<
> Binary has R+X to its DLL imports, optional RO or R+W to DLL's data;
> It has no access to DLLs it did not import directly.
>
> Things like heap data are harder, as stuff in these areas tends to be
> shared freely, and it would create needless hassle if something
> "malloc'ed" in one DLL were no-access from another. This needs R+W from
> everywhere in a program (or R+W+X on special request).
<
I have a hard time believing that it is necessary to have --E access to areas
on the heap, and probably a security hole.
>
> But, herein lies a few issues...
<
Indeed.

On 1/30/2022 2:45 PM, MitchAlsup wrote:
> On Sunday, January 30, 2022 at 2:34:43 PM UTC-6, BGB wrote:
>> On 1/30/2022 9:27 AM, Anton Ertl wrote:
>
>>> That's not the way I would describe it. There is some vulnerability
>>> (typically a buffer overflow) that lets the attacker write stuff into
>>> the attacked program where the programmer of the attacked program had
>>> not intended. And the attacked program then uses this stuff as an
>>> address (or something that's used for constructing an address), and
>>> that address needs to be right for the attacker to achieve his goal.
>>>
>> Yep.
>>
>> Buffer overflow is one context.
>>
>> Another is "theoretically sandboxed" code existing within the same
>> address space as the "not sandboxed" code hosting the sandbox (assuming
>> an absense of any other memory protection scheme, *).
>>
>> If the sandboxed code can guess addresses to things outside the sandbox,
>> it can break free.
>>
>>
>> *: My VUGID scheme was initially imagined mostly for these sorts of
>> scenarios.
>>
>>
>> However, making it both "strong" and "fully automatic" would pose issues.
>>
>> It could be applied semi-automatically on a DLL graph, say:
>> Binary has R+X to its .text section, and R+W to its data/bss;
> <
> Why does binary necessarily have R-E access to code (.text) pages?
> <
> My 66000 architecture gets rid of the need to have R-- access to code pages
> {Mainly because ISA eliminates need to read read-only data from the code pages}
> <

Read access can be eliminated, mostly just requires keeping things like
strings and similar separate from the '.text' section, probably keeping
them in '.rodata'.

Main practical effect though is that it does mean that either:
These two sections needs to be in entirely separate pages;
The page in the overlapping area still needs read privilege.

But, yeah, read access to executable code is technically unnecessary in
BJX2, and not having it is probably better from a security POV.

>> Binary has R+X to its DLL imports, optional RO or R+W to DLL's data;
>> It has no access to DLLs it did not import directly.
>>
>> Things like heap data are harder, as stuff in these areas tends to be
>> shared freely, and it would create needless hassle if something
>> "malloc'ed" in one DLL were no-access from another. This needs R+W from
>> everywhere in a program (or R+W+X on special request).
> <
> I have a hard time believing that it is necessary to have --E access to areas
> on the heap, and probably a security hole.

The R+W+X pages would be mostly needed for things like lambdas and
similar. Also for things like JIT compilers.

Though, I guess arguably it could make sense to have lambdas implemented
in a way that does not depend on publicly visible R+W+X memory (likely
by having the lambda's executable thunk and captured bindings in
separate locations).

This could also avoid a potential scenario where one could "hook"
execution by overwriting some other parties' lambdas.

>>
>> But, herein lies a few issues...
> <
> Indeed.

Yep...

MitchAlsup wrote:
> This seems like a good place to insert a potentially thread stealing question:
> <
> What happens to buffer overflow attacks when there is zero chance of the buffer
> overflow harming any control data (such as return address,...) ??
> <
> The buffer overflows and damages some data the application can read and write,
> but the return address, and preserved registers remain unmolested--so control is
> not stolen by this means.

I take your paycheck and deposit it into my account# leaving no audit trail.
And thank you very much.

> Though, I guess arguably it could make sense to have lambdas implemented in
> a way that does not depend on publicly visible R+W+X memory (likely by
> having the lambda's executable thunk and captured bindings in separate
> locations).

The "standard" representation of closures is to use an object whose first
field (or thereabout) points to the code of the function, and the other
fields contain the captured data. This keeps the code and the data
completely separate.

This is admittedly incompatible with the usual implementation of
function pointers in C (which are typically implemented as direct
references to code), but for most languages this is not an issue.

Stefan

On Sunday, January 30, 2022 at 6:22:38 PM UTC-6, Stefan Monnier wrote:
> > Though, I guess arguably it could make sense to have lambdas implemented in
> > a way that does not depend on publicly visible R+W+X memory (likely by
> > having the lambda's executable thunk and captured bindings in separate
> > locations).
<
> The "standard" representation of closures is to use an object whose first
> field (or thereabout) points to the code of the function, and the other
> fields contain the captured data. This keeps the code and the data
> completely separate.
<
Don't forget the arguments to the closure, which should be in the std
ABI locations.
>
> This is admittedly incompatible with the usual implementation of
> function pointers in C (which are typically implemented as direct
> references to code), but for most languages this is not an issue.
>
It is not a C-function in any way shape or form--at best one can say
that a c-function is a highly degenerate form of closure.
>
> Stefan

On 1/30/2022 12:45 PM, MitchAlsup wrote:
> On Sunday, January 30, 2022 at 2:34:43 PM UTC-6, BGB wrote:
>> On 1/30/2022 9:27 AM, Anton Ertl wrote:
>
>>> That's not the way I would describe it. There is some vulnerability
>>> (typically a buffer overflow) that lets the attacker write stuff into
>>> the attacked program where the programmer of the attacked program had
>>> not intended. And the attacked program then uses this stuff as an
>>> address (or something that's used for constructing an address), and
>>> that address needs to be right for the attacker to achieve his goal.
>>>
>> Yep.
>>
>> Buffer overflow is one context.
>>
>> Another is "theoretically sandboxed" code existing within the same
>> address space as the "not sandboxed" code hosting the sandbox (assuming
>> an absense of any other memory protection scheme, *).
>>
>> If the sandboxed code can guess addresses to things outside the sandbox,
>> it can break free.
>>
>>
>> *: My VUGID scheme was initially imagined mostly for these sorts of
>> scenarios.
>>
>>
>> However, making it both "strong" and "fully automatic" would pose issues.
>>
>> It could be applied semi-automatically on a DLL graph, say:
>> Binary has R+X to its .text section, and R+W to its data/bss;
> <
> Why does binary necessarily have R-E access to code (.text) pages?
> <
> My 66000 architecture gets rid of the need to have R-- access to code pages
> {Mainly because ISA eliminates need to read read-only data from the code pages}
> <
>> Binary has R+X to its DLL imports, optional RO or R+W to DLL's data;
>> It has no access to DLLs it did not import directly.
>>
>> Things like heap data are harder, as stuff in these areas tends to be
>> shared freely, and it would create needless hassle if something
>> "malloc'ed" in one DLL were no-access from another. This needs R+W from
>> everywhere in a program (or R+W+X on special request).
> <
> I have a hard time believing that it is necessary to have --E access to areas
> on the heap, and probably a security hole.

JITs?

On 1/30/2022 6:22 PM, Stefan Monnier wrote:
>> Though, I guess arguably it could make sense to have lambdas implemented in
>> a way that does not depend on publicly visible R+W+X memory (likely by
>> having the lambda's executable thunk and captured bindings in separate
>> locations).
>
> The "standard" representation of closures is to use an object whose first
> field (or thereabout) points to the code of the function, and the other
> fields contain the captured data. This keeps the code and the data
> completely separate.
>
> This is admittedly incompatible with the usual implementation of
> function pointers in C (which are typically implemented as direct
> references to code), but for most languages this is not an issue.
>

In my case, the lambdas are implemented as C function pointers, where C
function pointers are in turn implemented as a bare pointer to the first
instruction of the called function.

Granted, this does mean the need for the lambda to be an executable
stub, which mostly serves to load a pointer to the captured bindings
into a register and then branch to the main body of the lambda.

Usually ways to pull this off would then involve either dynamically
generating the stub (requires R+W+X memory or similar), or having an
array of preexisting stubs which are generated at compile time or
similar but then allocated at runtime (setting a finite limit of number
of lambdas which can exist at runtime).

....

On Sunday, January 30, 2022 at 8:42:03 PM UTC-6, Ivan Godard wrote:
> On 1/30/2022 12:45 PM, MitchAlsup wrote:
> > On Sunday, January 30, 2022 at 2:34:43 PM UTC-6, BGB wrote:
> >> On 1/30/2022 9:27 AM, Anton Ertl wrote:
> >
> >>> That's not the way I would describe it. There is some vulnerability
> >>> (typically a buffer overflow) that lets the attacker write stuff into
> >>> the attacked program where the programmer of the attacked program had
> >>> not intended. And the attacked program then uses this stuff as an
> >>> address (or something that's used for constructing an address), and
> >>> that address needs to be right for the attacker to achieve his goal.
> >>>
> >> Yep.
> >>
> >> Buffer overflow is one context.
> >>
> >> Another is "theoretically sandboxed" code existing within the same
> >> address space as the "not sandboxed" code hosting the sandbox (assuming
> >> an absense of any other memory protection scheme, *).
> >>
> >> If the sandboxed code can guess addresses to things outside the sandbox,
> >> it can break free.
> >>
> >>
> >> *: My VUGID scheme was initially imagined mostly for these sorts of
> >> scenarios.
> >>
> >>
> >> However, making it both "strong" and "fully automatic" would pose issues.
> >>
> >> It could be applied semi-automatically on a DLL graph, say:
> >> Binary has R+X to its .text section, and R+W to its data/bss;
> > <
> > Why does binary necessarily have R-E access to code (.text) pages?
> > <
> > My 66000 architecture gets rid of the need to have R-- access to code pages
> > {Mainly because ISA eliminates need to read read-only data from the code pages}
> > <
> >> Binary has R+X to its DLL imports, optional RO or R+W to DLL's data;
> >> It has no access to DLLs it did not import directly.
> >>
> >> Things like heap data are harder, as stuff in these areas tends to be
> >> shared freely, and it would create needless hassle if something
> >> "malloc'ed" in one DLL were no-access from another. This needs R+W from
> >> everywhere in a program (or R+W+X on special request).
> > <
> > I have a hard time believing that it is necessary to have --E access to areas
> > on the heap, and probably a security hole.
> JITs?
<
With 12 cycle context switches, JITs run under a different memory map, the Jitter
itself only has RW- permissions as it should not be running its own JITed code.
<
The JIT should probably run at a different priority level than application, too.
<
With the My 66000 way of managing memory it is possible for the JIT to allocate
its JIT cache in the application address space.

On Sunday, January 30, 2022 at 9:06:00 PM UTC-6, BGB wrote:
> On 1/30/2022 6:22 PM, Stefan Monnier wrote:
> >> Though, I guess arguably it could make sense to have lambdas implemented in
> >> a way that does not depend on publicly visible R+W+X memory (likely by
> >> having the lambda's executable thunk and captured bindings in separate
> >> locations).
> >
> > The "standard" representation of closures is to use an object whose first
> > field (or thereabout) points to the code of the function, and the other
> > fields contain the captured data. This keeps the code and the data
> > completely separate.
> >
> > This is admittedly incompatible with the usual implementation of
> > function pointers in C (which are typically implemented as direct
> > references to code), but for most languages this is not an issue.
> >
> In my case, the lambdas are implemented as C function pointers, where C
> function pointers are in turn implemented as a bare pointer to the first
> instruction of the called function.
<
In effect, you call a trampoline.
>
> Granted, this does mean the need for the lambda to be an executable
> stub, which mostly serves to load a pointer to the captured bindings
> into a register and then branch to the main body of the lambda.
>
> Usually ways to pull this off would then involve either dynamically
> generating the stub (requires R+W+X memory or similar), or having an
> array of preexisting stubs which are generated at compile time or
> similar but then allocated at runtime (setting a finite limit of number
> of lambdas which can exist at runtime).
>
> ...

On 1/30/2022 9:48 PM, MitchAlsup wrote:
> On Sunday, January 30, 2022 at 9:06:00 PM UTC-6, BGB wrote:
>> On 1/30/2022 6:22 PM, Stefan Monnier wrote:
>>>> Though, I guess arguably it could make sense to have lambdas implemented in
>>>> a way that does not depend on publicly visible R+W+X memory (likely by
>>>> having the lambda's executable thunk and captured bindings in separate
>>>> locations).
>>>
>>> The "standard" representation of closures is to use an object whose first
>>> field (or thereabout) points to the code of the function, and the other
>>> fields contain the captured data. This keeps the code and the data
>>> completely separate.
>>>
>>> This is admittedly incompatible with the usual implementation of
>>> function pointers in C (which are typically implemented as direct
>>> references to code), but for most languages this is not an issue.
>>>
>> In my case, the lambdas are implemented as C function pointers, where C
>> function pointers are in turn implemented as a bare pointer to the first
>> instruction of the called function.
> <
> In effect, you call a trampoline.

More or less, the current implementation does something like:
MOV cap_addr, R3 //Jumbo96 encoding
BRA entry_point //Also jumbo encoding.

R3 would otherwise be used for 'this' in method calls, but lambdas can't
have 'this', so the same register and mechanism is used for accessing
the captured bindings.

>>
>> Granted, this does mean the need for the lambda to be an executable
>> stub, which mostly serves to load a pointer to the captured bindings
>> into a register and then branch to the main body of the lambda.
>>
>> Usually ways to pull this off would then involve either dynamically
>> generating the stub (requires R+W+X memory or similar), or having an
>> array of preexisting stubs which are generated at compile time or
>> similar but then allocated at runtime (setting a finite limit of number
>> of lambdas which can exist at runtime).
>>
>> ...

Didn't mention, because of the way my C ABI works, doing it via an array
of reusable dynamically allocated stubs would have worked out being
considerably more expensive.

Decided to skip writing about it, but I am noting that the move to
128-bit pointers would effectively require a fairly non-trivial set of
modifications to the C ABI. In effect, it would be a different ABI (and
not binary compatible with 64-bit code).

It will also require XMOV, XGPR, and RiMOV as a starting point:
XMOV: Because this whole ABI is built on it...
XGPR: Register pressure, also "sensibility"
If a core can afford a 96-bit address space...
It can also afford to have 64 GPRs.
RiMOV: Mostly because I needed to use the Op64 encodings for XLEA.
...

But, then it is probably going to use more memory and be slower, so it
is very possible this ABI is "already dead" in this sense (and, at
present, its main "selling point" would be the ability to have automatic
bounds checking on normal C pointers).

Hmmm...

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>> ASLR is security by obscurity, which we all know is no security at all.
>>
>> "Security by obscurity" refers to not publishing the security
>> algorithm you are using in the hopes that the attacker will not be
>> able to find that out.
>
>SBO refers to using a lack of knowledge _other than the access key_
>to block access to information or things.

Says who? There is certainly no such exception made in
<https://en.wikipedia.org/wiki/Security_through_obscurity>.

>Clearly since both Spectre and Meltdown demos bypassed ASLR trivially,

Where can I read about that?

>its not obscure or expensive enough to be useful.

Whether ASLR makes things to too expensive to be useful depends on how
wide the original vulnerability is.

>We need to leave pointers so our own code can find those
>new locations and attackers can use those pointers
>to follow that trail of bread crumbs too.

Only if the original vulnerability exposes these pointers to the
attack. If they are in a different VMA, the attack already needs to
overcome one level of ASLR to get there.

>Also exception handlers effectively disable all the detectors.

In order for signal handlers to be a problem, the original
vulnerability must be in code that a signal handler returns control to
in case of a SIGSEGV (few application set up a signal handler for
SIGSEGV), or the vulnerability must allow the attacker to set up such
a signal handler; but even if you give the attacker write access to
some buffer and then execute it, the attacker needs to guess the
buffer address correctly in order to set up a signal handler. Of
course, with such a wide-open vulnerability, ASLR of this buffer may
not be enough to make it unattractive for an attack (e.g., if the
vulnerability is in a web service that is started once for every
connection).

>Something like Intel RTM atomic transaction user mode exception
>handlers make it cheap to disable all the detectors.

Also sounds like you presume a vulnerability that allows the attacker
to write and then execute a buffer. It also presumes that Intel RTM
actually works. Are there any CPUs where it is enabled? It is
certainly disabled in our most recent Intel Server (a Xeon(R)
W-1370P), and of course it does not exist on our AMD-based servers.

Anyway, sure, ASLR won't protect you if you give the attacker full
access. I may help if the attacker finds a small hole in your
program.

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

BGB <cr88192@gmail.com> writes:
>Meanwhile, on 32-bit x86, it was most commonly implemented as something
>like: load image with an offset that is a randomized multiple of 64
>bytes or so relative to the page base.

That sounds unlikely to me, as it would be incompatible with demand
paging. What I see is position-independent executables that are
demand-paged, so they can be mapped to start at arbitrary page
boundaries. I also don't see any new IA-32 binaries.

>Another is "theoretically sandboxed" code existing within the same
>address space as the "not sandboxed" code hosting the sandbox (assuming
>an absense of any other memory protection scheme, *).
>
>If the sandboxed code can guess addresses to things outside the sandbox,
>it can break free.

That's not much of a sandbox then. Sandboxing as in JavaScript relies
on bounds checking by the programming language (and typically falls
prey to vulnerabilities in C libraries in the language run-time).

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

On 1/31/2022 1:58 AM, Anton Ertl wrote:
> BGB <cr88192@gmail.com> writes:
>> Meanwhile, on 32-bit x86, it was most commonly implemented as something
>> like: load image with an offset that is a randomized multiple of 64
>> bytes or so relative to the page base.
>
> That sounds unlikely to me, as it would be incompatible with demand
> paging. What I see is position-independent executables that are
> demand-paged, so they can be mapped to start at arbitrary page
> boundaries. I also don't see any new IA-32 binaries.
>

IIRC, it would be randomized the first time the DLL was loaded by a
program, with fix-ups being applied at that stage. Typically they could
be shared with another process if that region of virtual addresses were
also free in the new process, otherwise a fresh / clean copy would be
loaded (and base relocs applied to fix it up to the address it was being
loaded into).

Position-independent code wasn't really a thing (with PE/COFF images
being base-relocatable but tending to use absolute addressing). For X64
is seems to be a mix of absolute and PC relative addressing.

Typically, the main executable would not use ASLR (in their great
wisdom, EXE's didn't generally contain base relocations). For a while,
it was typically only applied (by default) for OS level programs (for
user programs, ASLR not being used out of fear of potentially breaking
old binaries or similar).

This was all very much different from Linux though, which did generally
uses PIC binaries and demand paging.

I haven't looked as much into how Linux did ASLR though.

>> Another is "theoretically sandboxed" code existing within the same
>> address space as the "not sandboxed" code hosting the sandbox (assuming
>> an absense of any other memory protection scheme, *).
>>
>> If the sandboxed code can guess addresses to things outside the sandbox,
>> it can break free.
>
> That's not much of a sandbox then. Sandboxing as in JavaScript relies
> on bounds checking by the programming language (and typically falls
> prey to vulnerabilities in C libraries in the language run-time).
>

This is what often passed for sandboxing. Say, you run the program with
fake DLLs in place of the real ones, which would redirect calls into the
program which manages the sandbox (typically part of an antivirus
program or similar), which would then sanity check them before handing
them off to the OS.

In theory, the binary could break free of the sandbox if it realized it
was in a sandbox and recognized the antivirus software or similar that
was sandboxing it. Eg, a relative danger of the "try to run program in a
sandbox and see if it does something suspicious" strategy. This might be
used for unrecognized (and non-whitelisted) binaries which otherwise
passed the checks which involve calculating a file hash and looking it
up in a database (then, say, if it runs without incident, the AV adds it
to a whitelist and it runs natively after this).

Or such...

Anton Ertl wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>> Anton Ertl wrote:
>>> EricP <ThatWouldBeTelling@thevillage.com> writes:
>>>> ASLR is security by obscurity, which we all know is no security at all.
>>> "Security by obscurity" refers to not publishing the security
>>> algorithm you are using in the hopes that the attacker will not be
>>> able to find that out.
>> SBO refers to using a lack of knowledge _other than the access key_
>> to block access to information or things.
>
> Says who? There is certainly no such exception made in
> <https://en.wikipedia.org/wiki/Security_through_obscurity>.

"There is scant formal literature on the issue of security through
obscurity. Books on security engineering cite Kerckhoffs' doctrine
from 1883, if they cite anything at all."

https://en.wikipedia.org/wiki/Kerckhoffs%27_principle

which says
"The principle holds that a cryptosystem should be secure, even if
everything about the system, except the key, is public knowledge."

>> Clearly since both Spectre and Meltdown demos bypassed ASLR trivially,
>
> Where can I read about that?

The original 2018 Spectre paper cites 3 papers on ASLR bypass.
It also outlines in their text how they compensate for ASLR, e.g.:

"For indirect branch poisoning, we targeted the first instruction of
the Sleep() function, where both the location of the jump destination
and the destination itself change per reboot due to ASLR."

Spectre Attacks: Exploiting Speculative Execution, 2018
https://arxiv.org/abs/1801.01203

A quick search finds a 2021 Reg article on ASLR bypass

Google looks at bypass in Chromium's ASLR security defense,
throws hands up, won't patch garbage issue, 26-Feb-2021
https://www.theregister.com/2021/02/26/chrome_aslr_bypass/

which references a 2017 paper that predates the Spectre publication
on how to bypass ASLR and supposedly claims that it is unfixable

ASLR on the Line: Practical Cache Attacks on the MMU, 2017
https://download.vusec.net/papers/anc_ndss17.pdf

>> its not obscure or expensive enough to be useful.
>
> Whether ASLR makes things to too expensive to be useful depends on how
> wide the original vulnerability is.
>
>> We need to leave pointers so our own code can find those
>> new locations and attackers can use those pointers
>> to follow that trail of bread crumbs too.
>
> Only if the original vulnerability exposes these pointers to the
> attack. If they are in a different VMA, the attack already needs to
> overcome one level of ASLR to get there.

I gather from those papers that is quite doable.

>> Also exception handlers effectively disable all the detectors.
>
> In order for signal handlers to be a problem, the original
> vulnerability must be in code that a signal handler returns control to
> in case of a SIGSEGV (few application set up a signal handler for
> SIGSEGV), or the vulnerability must allow the attacker to set up such
> a signal handler; but even if you give the attacker write access to
> some buffer and then execute it, the attacker needs to guess the
> buffer address correctly in order to set up a signal handler. Of
> course, with such a wide-open vulnerability, ASLR of this buffer may
> not be enough to make it unattractive for an attack (e.g., if the
> vulnerability is in a web service that is started once for every
> connection).

The signal handler isn't a problem, it is the one of the tools used for
disabling de-randomization by allowing attackers to probe for addresses.

>> Something like Intel RTM atomic transaction user mode exception
>> handlers make it cheap to disable all the detectors.
>
> Also sounds like you presume a vulnerability that allows the attacker
> to write and then execute a buffer. It also presumes that Intel RTM
> actually works.

RTM puts a cheap user mode exception handler into the attackers hands.
They can repurpose it to get much higher performance attacks because
the exception doesn't have to do a trip through OS and C signals.

> Are there any CPUs where it is enabled? It is
> certainly disabled in our most recent Intel Server (a Xeon(R)
> W-1370P), and of course it does not exist on our AMD-based servers.

I haven't been following it.

> Anyway, sure, ASLR won't protect you if you give the attacker full
> access. I may help if the attacker finds a small hole in your
> program.
>
> - anton