Re: [RFC PATCH 1/5] rseq: uapi: add rseq operation definitions

[Thomas Gleixner]

On Tue, Sep 08 2026 at 19:31, Florian Weimer wrote:
>>> Would it be possible to use actual CPU instructions running in userspace
>>> for this?  I assume not because it's not possible to restore the
>>> register contents.
>>
>> Well I had in mind another solution, albeit some might find it ugly but
>> I think it does have the merit to be explored.
>>
>> Basically, instead of doing all the operations in the kernel, we could
>> setup something akin to a signal handler by pushing a frame on the
>> userspace stack and resuming the execution of the thread into that
>> "handler".  Userspace is now responsible of everything, including
>> returning to the original IP.
>
> On mere context switch (not signal delivery), I don't think the kernel
> assumes that there is a valid stack pointer.  These scheme would change
> that.  This would be fine for managed code, but this scheme has to work
> with arbitrary code that reassigns registers temporarily.

You are right that aside of signal handling there is no assumption, but
as signal handling can happen at arbitrary times user space should not
play with SP unless there is an alternative signal stack, which has its
own nasties as we all know.

If there is truly code which needs to trainwreck SP for a sane reason
and not just because and has a good reason to utilize such a
library/functionality, then we can work around that by a mandating a
separate "fixup" stack per thread to enable this functionality. Then the
screwed up user space stack pointer becomes completely irrelevant and
the only interesting register on the kernel entry stack is the return IP
which got pushed by the hardware. And provide an option to work without
this indirection of course. :)

There are probably other solutions, but I really want to move this to
user space and not introduce yet another limited single purpose
"interpreter" in the kernel, which will be "extended" and duct taped
forever.

TBH. At some point we have to stop pretending that we can support all
possible insanities and their arbitrary combination. That just limits
ourself and puts the burden and the complexity into the wrong places
just because.

Thanks,

        tglx