Josh Elsasser <j...@elsasser.org> wrote: > On Fri, Jan 27, 2023 at 05:02:33PM +0100, Christian Weisgerber wrote: > > lang/sbcl will not work with x-only. > > > > I took another look at the warnings about data directives in .text. > > In runtime/x86-64-assem.S we have snippets like these: > > > > GNAME(fun_end_breakpoint_trap): > > TRAP > > .byte trap_FunEndBreakpoint > > hlt # We should never return here. > > > > GNAME(do_pending_interrupt): > > TRAP > > .byte trap_PendingInterrupt > > ret > > > > GNAME(memory_fault_emulation_trap): > > TRAP > > .byte trap_MemoryFaultEmulation > > > > Where TRAP is defined to int3, and trap_* are consecutively numbered > > constants. The other half of this is sigtrap_handler() in > > runtime/x86-64-arch.c, which reads the byte after the int3 instruction > > > > trap = *(unsigned char *)OS_CONTEXT_PC(context); > > > > and then dispatches accordingly. > > > > ... And this brief analysis marks the end of my own involvement > > with this port. > > Unfortunately I don't have a new enough CPU to test xonly, so someone > should probably mark it USE_NOEXECONLY >
It sounds like that could be fixed by removing that .byte, and creating some other sort of fast-lookup method that looks up the PC it came from to decide where it came from. But that's a problem for upstream. If upstream ever wants to run on xonly systems. Will xonly systems become popular in the next 10 years? I suspect they will... people said W^X and lots of other cheap security mitigations were unreasonable and would never make it into other operating systems and what happened?
