lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ldmuxzcs.ffs@tglx>
Date: Thu, 04 Sep 2025 12:53:55 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, LKML
 <linux-kernel@...r.kernel.org>, Jens Axboe <axboe@...nel.dk>, Peter
 Zijlstra <peterz@...radead.org>, "Paul E. McKenney" <paulmck@...nel.org>,
 Boqun Feng <boqun.feng@...il.com>, Paolo Bonzini <pbonzini@...hat.com>,
 Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
 x86@...nel.org, Arnd Bergmann <arnd@...db.de>, Heiko Carstens
 <hca@...ux.ibm.com>, Christian Borntraeger <borntraeger@...ux.ibm.com>,
 Sven Schnelle <svens@...ux.ibm.com>, Huacai Chen <chenhuacai@...nel.org>,
 Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
 <palmer@...belt.com>
Subject: Re: [patch V2 25/37] rseq: Rework the TIF_NOTIFY handler

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 :)

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ