Re: [patch V2 25/37] rseq: Rework the TIF_NOTIFY handler

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

On 2025-09-04 06:53, Thomas Gleixner wrote:
> On Thu, Sep 04 2025 at 02:52, Sean Christopherson wrote:
>> On Tue, Sep 02, 2025, Thomas Gleixner wrote:
>>>> I don't think any virt user should expect the userspace fields to be
>>>> updated on the host process while running in guest mode, but it's good
>>>> to clarify that we intend to change this user-visible behavior within
>>>> this series, to spare any unwelcome surprise.
>>>
>>> Actually it is not really a user-visible change.
>>
>> It's definitely a user-visible change in the sense that userspace, via the guest,
>> will see different behavior.
>>
>>> TLS::rseq is thread local and any update to it becomes only visible to
>>> user space once the vCPU thread actually returns to user space. Arguably
>>> no guest has legitimately access to the hosts VCPU thread's TLS.
>>>
>>> You might argue, that GDB might look at the thread's TLS::rseq while the
>>> task runs in VCPUs guest mode. But that's completely irrelevant because
>>> once a task enters the kernel the RSEQ CPU/NODE/MM ids have no meaning
>>> anymore. They are only valid as long as the task runs in user space.
>>
>> Paravirt setups, e.g. hoisting host-controlled workloads into VMs, have explored
>> (ab)using rseq.  In such setups, host threads are often mapped 1:1 to vCPUs, in
>> which case the pCPU in particular becomes interesting.
> 
> Why am I not suprised?
> 
>>> When a task hits a breakpoint GDB can only look at the state _before_
>>> that and that's all what it can see when it looks at the TLS of a
>>> thread, which voluntarily went into the kernel via the KVM ioctl.
>>>
>>> That update is truly a kernel internal implementation detail and it got
>>> introduced way _after_ the initial RSEQ implementation.
>>
>> Yes, but that doesn't change the fact that a user _could_ have come to depend on
>> the current behavior sometime in the last ~5 years.
> 
> So it depends on a kernel internal implementation detail which happened
> to be introduced by chance rather by design and without any guaranteed
> behaviour vs. a guest.
> 
>> I'm ok formally stating that exposing rseq directly to a KVM guest is unsupported,
>> but I would like to explicitly call out and document the change.
> 
> Fair enough. I've amended the change log accordingly.
> 
> If that turns out to be a real world problem, then it needs to be
> brought back explicitly into the virt TIF work handling code, but I
> prefer not to :)

That works for me !

Thanks,

Mathieu

> 
> Thanks,
> 
>          tglx


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com