OSDev.org

Tim, how would you implement your "split" ? with segments, i guess, giving each task a DPL-3 code & data descriptor. But then the question remains: what prevents shared process A to guess process B's data selector and start writing into it ? they'll be both at a DPL of 3 ...

no, imho, you need to group process A's selectors in a specific LDTa and process B's selectors in LDTb, so that memory resources from A are invisible to B and vice versa.
The process structure could carry the base address for the process, so that all the kernel has to do to access user-mode datas is to add process_base_address to user_provided_offset and use it as an offset in its own map_everything_data_segment ...

note that paging-based data sharing will probably remain preferable to segments-based sharing if the programming language do not support segmented architecture (C does not )

Yes, I see your point now about needing an LDT to enforce inter-process protection. However, it might be advantageous to relax that. Processes are immune to wild pointer writes from other processes (at least those written in C) because a program would have to go to some effort to obtain another selector and to use it. However, it might be useful to be able to write to another process's memory without the kernel being involved. Having said that, 'normal' operating systems solve that by sharing memory explicitly using paging, and there's no reason why that couldn't be used here.

In any case, the kernel doen't need to look at the LDT when using its own far pointer reads and writes (for IPC), since it could have one DPL0 descriptor in the GDT for this.

Yes, I agree now: it would be best to give each process an LDT containing just null, code and data descriptors with the appropriate base address, along with kernel-only descriptors in the GDT for flat memory and each of the address space chunks.