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: References: <04876fc002ab019a74c78113a36622f3@www.novabbs.org> <20250120125537.000075e0@yahoo.com> <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 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.