From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 885ECC433EF for ; Thu, 16 Jun 2022 09:31:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232439AbiFPJbW (ORCPT ); Thu, 16 Jun 2022 05:31:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbiFPJbV (ORCPT ); Thu, 16 Jun 2022 05:31:21 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36D3D3BA67 for ; Thu, 16 Jun 2022 02:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=/FLWc2TEgQvR6Lestc/lCyA2NX/oAWdgoQaLyVOcOsg=; b=Mtv0e/0LUtujFXUBTyvN/ogSTh 2DwxkKZc8SnJ7MCr0ztCYUVLCD9GVP3jLiDiDZxjwviLX3Ljttry0RcUNaDwlQLO05yTG/DkaJvVF nfNYY6UFvtX6uIjmLp6mUoeezK5cRE73isYCZxMUohsm3bLZYWfl8kgnTlwyFsKZjnwDdpo58OVax 6RQO2f23hOUuscc3R14mclfwXPLsH13b88v8W6MBQoKRqndH0ha5FvJ3QebZMEhWypCLf3C19BvaB /eMeFfKf9J5AhnZG1QvK4YpBy5uqBVU/irEC5pxpESCitQdUvnxxY1xO65UhJ38+98hjbf81IS3pD 4peHHqlg==; Received: from dhcp-077-249-017-003.chello.nl ([77.249.17.3] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1o1lq0-008Nat-CN; Thu, 16 Jun 2022 09:30:53 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 0FEE630023F; Thu, 16 Jun 2022 11:30:50 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id EA3162014ABD6; Thu, 16 Jun 2022 11:30:49 +0200 (CEST) Date: Thu, 16 Jun 2022 11:30:49 +0200 From: Peter Zijlstra To: "Edgecombe, Rick P" Cc: "kirill.shutemov@linux.intel.com" , "Lutomirski, Andy" , "dave.hansen@linux.intel.com" , "linux-kernel@vger.kernel.org" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "kcc@google.com" , "andreyknvl@gmail.com" , "ak@linux.intel.com" , "dvyukov@google.com" , "x86@kernel.org" , "ryabinin.a.a@gmail.com" , "glider@google.com" Subject: Re: [PATCHv3 5/8] x86/uaccess: Provide untagged_addr() and remove tags before address check Message-ID: References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-6-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 13, 2022 at 05:36:43PM +0000, Edgecombe, Rick P wrote: > On Fri, 2022-06-10 at 17:35 +0300, Kirill A. Shutemov wrote: > > +#ifdef CONFIG_X86_64 > > +/* > > + * Mask out tag bits from the address. > > + * > > + * Magic with the 'sign' allows to untag userspace pointer without > > any branches > > + * while leaving kernel addresses intact. > > Trying to understand the magic part here. I guess how it works is, when > the high bit is set, it does the opposite of untagging the addresses by > setting the tag bits instead of clearing them. So: The magic is really rather simple to see; there's two observations: x ^ y ^ y == x That is; xor is it's own inverse. And secondly, xor with 1 is a bit toggle. So if we mask a negative value, we destroy the sign. Therefore, if we xor with the sign-bit, we have a nop for positive numbers and a toggle for negatives (effectively making them positive, -1, 2s complement yada-yada) then we can mask, without fear of destroying the sign, and then we xor again to undo whatever we did before, effectively restoring the sign. Anyway, concequence of all this is that LAM_U48 won't work correct on 5-level kernels, because the mask will still destroy kernel pointers. As such, this patch only does LAM_U57.