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

[Thomas Gleixner <tglx@kernel.org>]

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