Re: [patch 8/8] x86/vdso: Implement __vdso_futex_robust_try_unlock()

From: Thomas Gleixner

Date: Mon Mar 16 2026 - 17:07:03 EST


On Mon, Mar 16 2026 at 15:19, Mathieu Desnoyers wrote:
> On 2026-03-16 13:13, Thomas Gleixner wrote:
>> +
>> +static __always_inline void __user *x86_futex_robust_unlock_get_pop(struct pt_regs *regs)
>> +{
>> + return (void __user *)regs->dx;
>
> When userspace is compat 32-bit, with a 64-bit kernel, are we sure that
> the 32 upper bits are cleared ? If not can we rely on
> compat_robust_list_clear_pending to ignore those top bits in
> put_user(0U, pop) ?

Which compat version are you talking about?

1) A 32-bit application which truly runs as compat

2) A 64-bit application which uses both variants and invokes the
64-bit VDSO from a 32-bit program segment

#1 is inherently safe. The 32-bit application uses the compat 32-bit VDSO
which only accesses the lower half of the registers. So the mov $ptr,
%edx results in zero extending the 32-bit value. From the SDM:

"32-bit operands generate a 32-bit result, zero-extended to a
64-bit result in the destination general-purpose register."

The exception/interrupt entry switches into 64-bit mode, but due to
the above the upper 32 bit are 0. So it's safe to just blindly use
regs->dx.

Otherwise it would be pretty impossible to run 32-bit user space on a
64-bit kernel.

#2 can really be assumed to be safe as there must be some magic
translation in the emulation code which handles the different calling
conventions.

That's not any different when 32-bit code which runs in the context
of a 64-bit application invokes a syscall or a library function.

If that goes wrong, then it's not a kernel problem because the
application explicitely tells the kernel to corrupt it's own memory.

The golden rule of UNIX applies here as always:

Do what user space asked for unless it results in a boundary
violation which can't be achieved by user space itself.

IOW, let user space shoot itself into the foot when it desires to
do so.

Thanks,

tglx