Re: Constant Stack Canaries

On 4/3/2025 10:49 PM, Robert Finch wrote:

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.

I am not aware of this one. If it is in the privileged spec or similar, may have missed it.
Thus far, my core doesn't implement that much of the RV privileged spec, mostly just the userland ISA. If I wanted to run an RV OS, it is debatable if it would make more sense to try to mimic a hardware interface it understands, or have the "firmware" manage the real HW interfaces, and then fake the rest in software.

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

I am aware of at least a few CPU's that have banked register sets that may be backed to memory addresses (with the CPU itself evicting registers on context switch).
I have not done so.
I had considered the possibility of 4 rings each with their own set of registers. This could make things like interrupts and system calls cheaper, but (ironically) using this would make context switching more expensive.
An intermediate option could be a special RAM area for a "task cache", say, 8 or 16K, and then have a "Task Cache Miss" interrupt for cases where one tries to switch to a task's register bank that isn't in the cache. While a this would have a high cost (for a task cache miss), if the cache is bigger than the number of currently running tasks, it could still work out ahead.
But, better for performance would be if the task-cache were RAM backed and the HW spills and reloads from RAM (then, one could have maybe 64K or 256K or more for task register banks; probably enough for a decent number of active PIDs).
Though naive, "always save and restore all the registers to RAM" seems to have a fairly reasonable cost (and the among the lowest "actual task-switch cost", aside from the possibility of "let hardware lazily spill and reload register banks from main RAM", which could potentially be lower).
The main "bad" cost of switching between processes being the storm of TLB misses that would happen if not using a shared address space (granted, there are "global pages"). In my design, there are not true global pages, rather pages that are "global" within an ASID group (if the low 10 bits of the page's ASID are 0, it is assumed global within this group, whereas non-zero values are ASID specific; and the high 6 bits of the ASID gives the group, where pages are not global between groups).
Though, my existing OS, still being single address space, doesn't make use of this. The idea is that ASID will be tied to PID.
As how to best scale this past 1024 PIDs is unclear, likely the ASID will be modulo-1024, and needing to reassign a previously assigned ASID to a new PID would require a TLB flush.

>
         Stefan

>