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