Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Stacks, was Segments
Date: Tue, 21 Jan 2025 00:17:56 +0000
Organization: Rocksolid Light
Message-ID: <d9086bcc761ea79f8eebe5e4b0cb6018@www.novabbs.org>
References: <vdlgl9$3kq50$2@dont-email.me> <vmbd4n$3v6su$3@paganini.bofh.team> <vmbi6u$3js5u$1@dont-email.me> <04876fc002ab019a74c78113a36622f3@www.novabbs.org> <vmf5vv$2cse$1@gal.iecc.com> <lv18qpFjhe9U1@mid.individual.net> <vmj9hh$2bkbs$1@dont-email.me> <c0e894f1e2a4f551cb6d117cc00525ba@www.novabbs.org> <20250120125537.000075e0@yahoo.com> <vmlb3k$1314j$1@paganini.bofh.team> <43e21bd0bddea1733cd672c07a6319d4@www.novabbs.org> <20250121012519.00006d31@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="369536"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$YR4u6XNpgxu9xD5vMUz7fuNHveDmcgmNCT9ykXvYwhYh9TcCXkFZq
Bytes: 4420
Lines: 72

On Mon, 20 Jan 2025 23:25:19 +0000, Michael S wrote:

> On Mon, 20 Jan 2025 22:05:10 +0000
> mitchalsup@aol.com (MitchAlsup1) wrote:
>
>> On Mon, 20 Jan 2025 11:12:54 +0000, Waldek Hebisch wrote:
>>
>>> Michael S <already5chosen@yahoo.com> wrote:
>>>> On Sun, 19 Jan 2025 18:28:40 +0000
>>>> mitchalsup@aol.com (MitchAlsup1) wrote:
>>>>
>>>>>
>>>>> In My 66000 the code cannot read/write that other stack with LD
>>>>> and ST instructions. It can only be accessed by ENTER (stores)
>>>>> and EXIT (LDs). The mapping PTE is marked RWE = 000.
>>>>>
>>>>> So, while you can still overrun buffers, you cannot damage the
>>>>> call/ return stack or the preserved registers !!
>>>>
>>>> Not that I am a specialist in GC, but according to my understanding
>>>> the most common and the best performing variants of GC can not work
>>>> without read access to preserved registers. Compacting collector
>>>> seems to need write access as well.
>>>> As to return addresses, I would think that read access to stack of
>>>> return addresses is necessary for exception handling.
>>>
>>> _Correctness_ of GC depends on ability to see preserved registers
>>> and return address: return address may be the only live reference
>>> to some function and similarly for preserved registers.  On could
>>> try to work around lack of access using separate software-managed
>>> stack duplicating data from "hardware" stack, but that is ugly
>>> and is likely to kill any performance advantage from hardware
>>> features.
>>>
>>> BTW, the same holds for debuggers and exception handling.  Those
>>> clearly need some way to go around hardware limitations.
>>
>> Yes, there is a way to do all those things, but I am not in a position
>> to discuss due to USPTO rules.
>>
>> It is like there is a privilege level between application and GuestOS.
>> {{I spent all afternoon trying to think of a name for this privilege
>> above application "non-privileged" and below "privileged". Maybe
>> meso-privileged ?!?
>>
>
> Call it 'user'. Then rename the level that you now call 'application'
> to 'sandbox'.

Realistically--there are 3 levels in each privilege layer::

least) sandbox--for Jitted code
medium) {user, JIT, Dynamic library, ...}
higher) {debug, GC, Exception, interrupt, Dynamic loader, device DMA,
...}
{{none of which need access to other-than-user VAS, or other-than-user
privileges}}

All sharing a single address space, and a software stack of supervision,
interrupt table, file-ids, socket-ids,...

The higher level of privilege allows this level to disobey the
permissions
in the PTE (possibly under a flag from ROOT).

So, while sandbox is a fine name for the least privileged running
environment, we are still needing a for the medium level. It is almost
like the higher level is a good portion of GuestOS kernel--those parts
requiring no privilege in any normal sense.

>> I/O works similarly--in that to the application a page may be marked
>> RWE=001 (execute only) but the swap disk is allowed to read or write
>> those pages.