Re: lang/sbcl will not work with x-only

Josh Elsasser <josh@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?