From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F7DD34FF50 for ; Mon, 16 Mar 2026 21:02:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773694971; cv=none; b=kvGSPfot2mn3Fexn6u3FAAFfxAp6ZqGXhYimCz4rPcZR9a2o6t2/6jPWeWBWuQHlufU1e2O190FAB44hTD1IG/WXlFftMQe174XsgLuYw0F+bn5R7nAL14TpRVrYAy1xP1FEuJ5aWqHGs+hZVpIGFTeyr+iVQGcC1HR20QmP2vc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773694971; c=relaxed/simple; bh=iWiT2uNY+Nr+nkyW34YeaF76Cac0CVE/S0qyx0gLTg4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=b5PFNkolV5liVw2/CeKLPRYJMCagIDAR+xQ/2De2UYhyAYnpBNLAwZURMrxXhUjdBd4fIlgt4pu/iv0UcBkmE5QPSJf2g+8bkix8S62jwx/ndPVT+59eiCW6rrXKd51/fWIxZ+Twfwu9wPcKqUhyZwQO/1yDg/3XjbSRAiAXzG4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o17q4hh4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o17q4hh4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E37CAC19424; Mon, 16 Mar 2026 21:02:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773694970; bh=iWiT2uNY+Nr+nkyW34YeaF76Cac0CVE/S0qyx0gLTg4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o17q4hh4D/5hotkLEQT+6/DJ1Mt5Go2KNRTXgGSz9X1Cp0HY2fB1k6MKTE7MVuBuf hAsV6SGv0QTpc/D8mjfKvxm1EZQ1Cwvwk6LuO/oArESlxCTe83CyUP7so44esUGiSl vx+OZs70jhs8hYYUscWn8Zm53FI0oncb+jLOlqpUviojezH+8vrWOwIS/FL1djDXQN 1XLhYorzQBUMULBlglNVaZjB9umcYf9ncICsLsapYWDTFGM8E6BYLcRaiiC5TgkzQt pvHL/nttOyOSkQf+Wz1bSc6M7AMMBj7dW0nPyNF/Mz7rPDpQjxRPybg02qYgxxQduZ x6Hd2swx5ucbw== From: Thomas Gleixner To: Mathieu Desnoyers , LKML Cc: =?utf-8?Q?Andr=C3=A9?= Almeida , Sebastian Andrzej Siewior , Carlos O'Donell , Peter Zijlstra , Florian Weimer , Rich Felker , Torvald Riegel , Darren Hart , Ingo Molnar , Davidlohr Bueso , Arnd Bergmann , "Liam R . Howlett" Subject: Re: [patch 8/8] x86/vdso: Implement __vdso_futex_robust_try_unlock() In-Reply-To: <7b942738-231b-4168-8d97-0e5c974af2e9@efficios.com> References: <20260316162316.356674433@kernel.org> <20260316164951.484640267@kernel.org> <7b942738-231b-4168-8d97-0e5c974af2e9@efficios.com> Date: Mon, 16 Mar 2026 22:02:47 +0100 Message-ID: <87v7evo5c8.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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