Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1124344pxu; Sat, 24 Oct 2020 01:02:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxOmdau8dRrGUQmintoapsq+Va76Mxp5eG+NfYX/ZwBQh0/xnL5Za5Y/6OnjEf0OvwzWHDT X-Received: by 2002:a17:906:4a8d:: with SMTP id x13mr6015438eju.47.1603526543913; Sat, 24 Oct 2020 01:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603526543; cv=none; d=google.com; s=arc-20160816; b=hopV9wcvcs8iDYv0CBXylKbKxsZsS5XNw4T/KDCIqPsU9tv2dEKlfKsbShveV/qGA0 UgFLtuphUv7KmUzgu0PyPLNx01LLJR7kdQQCP3JaU8+XeOS0nWDR8jB7N1RZChuzipVY CT1xQSen0jGxdRd5D+JaINqtw3ZrDWfUmFu6XmKAHXAhDH4W7bjbt+W/R7crOGBihh6j xCxYGRtFpjDPJqVrVTRYy8Wt4IQqn5meFF6IM82x/0zyNMggh1+SDAXq9W5rYHfcn/cq fV52ocCoPD4qe+cg6/hMYdngdWvAgyHAwjk5B3N6rxhMp0Xo4IGQk0V9JYfU/bON0XWW wVfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=N+33wDxuGUMXB1ZwIVvPUPnsjfccIQOLpKMpJs/TYfg=; b=g+MbKH1QCNZIX2T6SZBBjcnrR/dICd2TDqqMemxZo/OYX7Y2sPI0Te+EwblXGbHafX 6thzVfFMy36u0kncUAk9bQB3OW8AGA456ka0DrM7FW5YjMsMmkCjRcddXQUY0hEco+q2 m1XizQ/SQ1fXr+jPlEh5HFbGdsYNBwe32+E9in+Ytnr17I2jLfsC3AHQZ6j/TaeNohRM sv+Kr0QI9AiSEhTA2uy+QWIku647vkCmSThZRL9CDmz5HB7B3LMHlfbJlAVasyAR5gmU DjWBkIwy75z4bL/6yW/ioucwpz8FbOUwylLzEOJm3Fq8SdXvIFpSDz1dqdwwN1hefRpn QYNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=R+l99qoy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o7si2711405ejr.747.2020.10.24.01.01.48; Sat, 24 Oct 2020 01:02:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=R+l99qoy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756292AbgJWUmy (ORCPT + 99 others); Fri, 23 Oct 2020 16:42:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:56316 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756266AbgJWUmw (ORCPT ); Fri, 23 Oct 2020 16:42:52 -0400 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 20B0C20BED for ; Fri, 23 Oct 2020 20:42:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603485772; bh=Fk71VNnpG9mPOHqXxWhqfVK24UDAqMPprfF4A9wGV5s=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=R+l99qoyzsqml9wORw+7aeHGQ8iEWi7TOQoVrQd7BnBuUqU79Jxgzn/P85uwdU8Fu ASigjKT9LMHwW52ZLFo5ZyOdUQBHZ/U5+JJbNc6bA7VppmnJ2+lkLAqVX8nPB1dZj7 OKIcHvqnbRJCDLOyoP5mWrK53/FBERrBOAmU+LB8= Received: by mail-wm1-f49.google.com with SMTP id d3so3468277wma.4 for ; Fri, 23 Oct 2020 13:42:52 -0700 (PDT) X-Gm-Message-State: AOAM533CE2euwFigLGKbMUroaQbhtg2N2aKdsyvCSlChdadb0imrS7cQ So9WoyR8NYoImVXSPlwpq1qi7VI+uH122tqRwEj0wg== X-Received: by 2002:a05:600c:2241:: with SMTP id a1mr4254477wmm.49.1603485770484; Fri, 23 Oct 2020 13:42:50 -0700 (PDT) MIME-Version: 1.0 References: <20201023203154.27335-1-linux@rasmusvillemoes.dk> In-Reply-To: <20201023203154.27335-1-linux@rasmusvillemoes.dk> From: Andy Lutomirski Date: Fri, 23 Oct 2020 13:42:39 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/uaccess: fix code generation in put_user() To: Rasmus Villemoes Cc: Linus Torvalds , Thomas Gleixner , Ingo Molnar , Borislav Petkov , X86 ML , "H. Peter Anvin" , Sean Christopherson , Naresh Kamboju , LKML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes wrote: > > Quoting > https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html: > > You can define a local register variable and associate it with a > specified register... > > The only supported use for this feature is to specify registers for > input and output operands when calling Extended asm (see Extended > Asm). This may be necessary if the constraints for a particular > machine don't provide sufficient control to select the desired > register. > > On 32-bit x86, this is used to ensure that gcc will put an 8-byte > value into the %edx:%eax pair, while all other cases will just use the > single register %eax (%rax on x86-64). While the _ASM_AX actually just > expands to "%eax", note this comment next to get_user() which does > something very similar: > > * The use of _ASM_DX as the register specifier is a bit of a > * simplification, as gcc only cares about it as the starting point > * and not size: for a 64-bit value it will use %ecx:%edx on 32 bits > * (%ecx being the next register in gcc's x86 register sequence), and > * %rdx on 64 bits. > > However, getting this to work requires that there is no code between > the assignment to the local register variable and its use as an input > to the asm() which can possibly clobber any of the registers involved > - including evaluation of the expressions making up other inputs. This looks like the patch is an improvement, but this is still IMO likely to be very fragile. Can we just do the size-dependent "a" vs "A" selection method instead? Sure, it's a little more code, but it will be Obviously Correct. As it stands, I can easily see our code failing on some gcc or clang version and the compiler authors telling us that we're relying on unsupportable behavior.