<story><title>Pointer Tagging for x86 Systems</title><url>https://lwn.net/SubscriberLink/888914/e81588082fa3b858/</url></story><parent_chain></parent_chain><comment><author>ChuckMcM</author><text>The UAI feature is nice! Back when I was noodling on creative ways to use 64 bit addresses the idea of a 16 bit &amp;#x27;space id&amp;#x27; was bandied about. A space ID in the upper 16 bits would indicate the address space for a particular thing, be it a process, the kernel, a shared library, etc. And a new opcode to trampoline from one space to another for doing things like system calls or library calls, could provide a gateway for doing secure code analysis (basically no &amp;quot;side&amp;quot; entrances into a space) and it would be a much more robust pointer testing mechanism because any read or write with a pointer &amp;quot;outside&amp;quot; the space would be immediately flagged as an error. The use of segments was sort of like this on the 286.&lt;p&gt;Ideally you&amp;#x27;d have a fine grained page map so that you could avoid copies from one space to another (instead of copy_in()&amp;#x2F;copy_out() you would do map_in()&amp;#x2F;map_out()) to get access to physical memory, while preserving the semantic that when something was mapped out of your space you couldn&amp;#x27;t affect it.(zero copy network stacks have been known to have issues when a process left holding a pointer to a buffer modified it when it wasn&amp;#x27;t &amp;quot;owned&amp;quot; kinds of bugs)&lt;p&gt;Could be a fun project for a RISC-V design. Not sure how many people are experimenting with various MMU systems but it is at least &lt;i&gt;possible&lt;/i&gt; to do these kinds of things in nominally &amp;quot;real&amp;quot; hardware (it has always been possible to simulate of course).</text></comment>
<story><title>Pointer Tagging for x86 Systems</title><url>https://lwn.net/SubscriberLink/888914/e81588082fa3b858/</url></story><parent_chain></parent_chain><comment><author>wongarsu</author><text>Instead of dealing with all the complexities of giving user processes control over the CPU&amp;#x27;s pointer masking with all the involved complexities of context switching and processes now using bit 63 (which marks kernel addresses), why doesn&amp;#x27;t the kernel just turn the feature on system wide when available, reserve a couple bits for kernel usage (like say bit 63 to mark kernel addresses) and provide a syscall that simply informs processes which bits they can use for pointer tagging, if any.&lt;p&gt;Are there any compatibility concerns that make it necessary to keep faulting on addresses outside the valid address range?</text></comment>