Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Robert Finch <robfi680@gmail.com>
Newsgroups: comp.arch
Subject: Re: Constant Stack Canaries
Date: Thu, 3 Apr 2025 23:49:31 -0400
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vsnksc$2fkk9$1@dont-email.me>
References: <vsbcnl$1d4m5$1@dont-email.me> <vsc058$20pih$1@dont-email.me>
 <4cf60b5fd8b785feb07a67a823cc349d@www.novabbs.org>
 <vseeen$l4ig$1@dont-email.me> <vseiq9$qndj$1@dont-email.me>
 <e05e9d429f71944bbfe74c3f54b79a03@www.novabbs.org>
 <vseojq$112f7$1@dont-email.me>
 <62b5c4a25d917c5bab64a815189de826@www.novabbs.org>
 <vshf6a$3smcv$1@dont-email.me>
 <21397906a7a77c2d43191fdaab98a3c9@www.novabbs.org>
 <jwv4iz75l6k.fsf-monnier+comp.arch@gnu.org> <vsidun$sput$2@dont-email.me>
 <jwvtt752vg1.fsf-monnier+comp.arch@gnu.org> <vsmg8a$16gr3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 04 Apr 2025 05:49:32 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="bda43583fe73b06b27f211a841600c64";
	logging-data="2609801"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/lctyshmvjnfOmio/QI3eIgUZuXkg+lWo="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:vIZSW4AiqcEIszV20HkU8Au4Wi8=
In-Reply-To: <vsmg8a$16gr3$1@dont-email.me>
Content-Language: en-US

On 2025-04-03 1:22 p.m., BGB wrote:
> On 4/3/2025 9:09 AM, Stefan Monnier wrote:
>> BGB [2025-04-01 23:19:11] wrote:
>>> But, yeah, inter-process function pointers aren't really a thing, and 
>>> should
>>> not be a thing.
>>
>> AFAIK, this point was brought in the context of a shared address space
>> (I assumed it was some kind of SASOS situation, but the same thing
>> happens with per-thread data inside a POSIX-style process).
>> Function pointers are perfectly normal and common in data (even tho they
>> may often be implicit, e.g. within the method table of objects), and the
>> whole point of sharing an address space is to be able to exchange data.
>>
> 
> Or, to allow for NOMMU operation, or reduce costs by not having context 
> switches result in as large of numbers of TLB misses.
> 
> Also makes the kernel simpler as it doesn't need to deal with each 
> process having its own address space.

Have you seen the MPRV bit in RISCV? Allows memory ops to execute using 
the previous mode / address space. The bit just has to be set, then do 
the memory op, then reset the bit. Makes it easy to access data using 
the process address space.
> 
> 
> Some data sharing is used for IPC, but directly sharing function 
> pointers between processes, or local memory (stack, malloc, etc), is not 
> allowed.
> 
> 
> Though, things may change later, there is a plan to more to separate 
> global/local address ranges. Likely things like code will remain in the 
> shared range, and program data will be in the local range.
>
Thinking of having a CPU local address space in Q+ to store vars for 
that particular CPU. It looks like only a small RAM is required. I guess 
it would be hardware thread local storage. May place the RAM in the CPU 
itself.

>>
>>          Stefan
>