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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A336C3DA7A for ; Mon, 2 Jan 2023 19:05:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2FD2B8E0002; Mon, 2 Jan 2023 14:05:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DEBD8E0001; Mon, 2 Jan 2023 14:05:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 19B988E0002; Mon, 2 Jan 2023 14:05:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0B31D8E0001 for ; Mon, 2 Jan 2023 14:05:42 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B8F9FAAC4F for ; Mon, 2 Jan 2023 19:05:41 +0000 (UTC) X-FDA: 80310788082.10.CDED4EC Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) by imf08.hostedemail.com (Postfix) with ESMTP id E348E160012 for ; Mon, 2 Jan 2023 19:05:38 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=QDUJtrnw; dmarc=none; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672686339; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=EKRJQffX4Q2GU/cYCvZE68D484wrxP9lYTVgY7yap7g=; b=Ytb1OKSxjUFdwyXy3z3qp7yFCKPaeHTwouV0JnPnLr/eWlHukKKNgYqj8Yqj+hT7ZbGCDe Suu6m6fXHllVNtHBL60UMcYSe14ih2lTnnxg0HkxlifEssMx1YDMf+zVljKCbTaNQNFb9t MC5CD9xRiYGqyDu3DyPzrpsEhHNDtEk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=QDUJtrnw; dmarc=none; spf=pass (imf08.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.217.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672686339; a=rsa-sha256; cv=none; b=UWU5HR69bp3uBM80jc64N97P5xOKD4RfGTlcejszL9KRmPHjHeavTdZPsuIaEAnlNHLBgK tzYS8mHiPJiKtFO/xOLucntXOFGSvRTinoYpy04pksG2XC2OeGlfRMlxQ40EROvazcmp6i LZxocqdmtP+a2IRO9/pif0IJDAp8lew= Received: by mail-vs1-f46.google.com with SMTP id a66so29714755vsa.6 for ; Mon, 02 Jan 2023 11:05:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EKRJQffX4Q2GU/cYCvZE68D484wrxP9lYTVgY7yap7g=; b=QDUJtrnwEeJUW8MAuyZ97d3xxWTSeHLM0KUL9jiGpE5qCjS3hQ5pSmBrXQussL+dqf cahzBacA4pw+IO33VyszoFXYiz/oGUpmYZA3IE2pA1T52T/Q5Kb7otZpoze8yCHH23R0 KLu5QOMG/3FIMIexSrvage/lS3YMvRNM6cK2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EKRJQffX4Q2GU/cYCvZE68D484wrxP9lYTVgY7yap7g=; b=DzgcGiW+oROAAxt5kdE+3DrbS+aRbDGVVXglndn2QUsTHRcrAt1vK585V6zOLaUi6I JkMdMlG5QBxAM4EmYAbqlOz7KpQ7v769ZfnUJD2UayD0aiTqUtbGefxcVOFon+fHZwVY J8OGS0zexJH1l0fgvoEBR7CW9OaCZ9lSZV5aNtyDAt1FQtiIDLRBG5m1rBTqkaEneS3A GD7adjvSFpamhK1bkzu3G/FX4zOIGK1n3hMMYdQVfRERnv8YU698G2y/n9Xgs1Pn0RDX 0J+nz+zx/6hZCn73jItxCCwdy0NidpkqBpz+4FoiiUgB5VDINGdZ7z/zZ0JK4XX+XRqO ic5A== X-Gm-Message-State: AFqh2kpdYpkBjPAL6EicUWoO92MoP2W6aIw7Ei837SktCJnNBZkVmrma 7hKCsFDU5kcTIQiF/452EyG1M6104VGv0p+q X-Google-Smtp-Source: AMrXdXsUe/mewtqZCkzhNV82CJexu1Qgcn9DDyd+xBdPNXegwCmMgBxxJQHtPNpxZiYWdCO6Aa/c/A== X-Received: by 2002:a05:6102:4408:b0:3c5:68f3:2024 with SMTP id df8-20020a056102440800b003c568f32024mr18012038vsb.9.1672686337456; Mon, 02 Jan 2023 11:05:37 -0800 (PST) Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com. [209.85.219.49]) by smtp.gmail.com with ESMTPSA id f9-20020a05620a280900b0070531c5d655sm6804770qkp.90.2023.01.02.11.05.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 02 Jan 2023 11:05:36 -0800 (PST) Received: by mail-qv1-f49.google.com with SMTP id q10so20129929qvt.10 for ; Mon, 02 Jan 2023 11:05:36 -0800 (PST) X-Received: by 2002:a05:6214:568c:b0:531:7593:f551 with SMTP id lm12-20020a056214568c00b005317593f551mr1532254qvb.89.1672686336079; Mon, 02 Jan 2023 11:05:36 -0800 (PST) MIME-Version: 1.0 References: <20221227030829.12508-1-kirill.shutemov@linux.intel.com> <20221227030829.12508-6-kirill.shutemov@linux.intel.com> <20221231001029.5nckrhtmwahb65jo@box> <4cf29f7a1a0041da818ac7ef598d142e@AcuMS.aculab.com> In-Reply-To: <4cf29f7a1a0041da818ac7ef598d142e@AcuMS.aculab.com> From: Linus Torvalds Date: Mon, 2 Jan 2023 11:05:20 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCHv13 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check To: David Laight Cc: "Kirill A. Shutemov" , "Kirill A. Shutemov" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , "x86@kernel.org" , Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Taras Madan , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , Bharata B Rao , Jacob Pan , Ashok Raj , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E348E160012 X-Stat-Signature: gcttir9ikjt66iq81ipa984q9pktubfu X-HE-Tag: 1672686338-620684 X-HE-Meta: U2FsdGVkX1/m2g3Rl/bPQ/Mm0CE+ji9PvBRbHXalM5zTj+9IRGMD9RJHITq6y8J5Es71yP9Q4AmpD/INgveGDoRu0lv+Xj5owvzoq6ndnVSeAoLCD2AcKUTDej5nTSWmtzaD/p0pJQY2V/ekaN6rtUlxojdEs5ziT/K6WWO6u4nUaG/DOTv068dOWd+OEHCoEW46Nd3DT6T6+zNxM++ZzjuJcwUDI60tl/36UHr1tzLZqmRwmg9DTvxY4vJWxEKhZb7XUBvXmP2PbXcIaiNuWaE3c5PzaqVZGgaqia89BR6dnB4FiXpAGhdSPgqAPZ3To6F0Y+gmW2zSLI/VWaM1MwuHpvoLFwqv3w2L4eI1VKxyQdJhWGT0pTP2NLKnFbkwbXiGeh9udhbIN8rw4o3Dk4A+MTneeucDPnuA3jQskJCDwDKxIZ0fAoBHY0vgO84y3EtNASPYxltxyuveZwVt4rdmmHX0/wV82XmkPCDnB+4H1WjyJAPkF3soBNQzlqm+JPqBjuo+hBd5ZVLP9w9zgh1tEDNKsbglbyL5KHLkjt9SdJ8QEXqKjNpxRKZPF7giONLg0tijP6yMq8/eOXCjAvELrCaoAS+X3P9fBLiUzDA1Xj/iIs26oLXhHUgmuE+bQhZOixXcjJroGj7oZHZD9Mj33iU7vjWU7xlEUVASFmiccVN3eImuVO+KvP6nCGSZI9XE5Yzn6dGMXQ2zn2BtBIviLqCHezQZVvlTz6B/BSspKb3nLRgIT1yPStl3ysH5yfDZBgpsedg3vVlPFuRaWiA9pRUfrp7dFSBBtFmzn9oxpdcxAcMDZUpqfD1RQ8m7tl8vkFzNeB0MLq7K0WFYhw9P8o1P+OGLQQBZVa2Zecux3aq3dgs6am8jbg+RpSjevE7BkZBeKTqDnHPjMR7tOXY9/xUynLYL9Q5poMUUPrtuxuNMQro4H59Wk2iuejTHPSXUjQZS2zG0qGF3d2p 54pwQye7 I6Hh4hcF4BsxnC4bqT3cvqHvs4b8wZnk7GJ0W6FrCks8tVIB9T77nShPT9+vWZOkqkdv8kac2G5ArbWhK3/57eJY69GtwQf7CFIES4yxLDpApxdMDenkS2My/MOdhCyAnvf/EGkuzhzA9dIWj6PfoLJ3IakadYxFK0g4t19rb5i2tsTn5idSVZZ2mkmA7zLM2TffPFK05vR2QzjMZGwXx9vvY7bxg+l+PxHYFr+ijqP4U48s9XolY8sC/A6Qw+B/quYAbn4/DxXlh9aJCPH9Hg/ftXUdZZYVTgA3LmN4qwQ71NulYS5fD5d9VCtOH74xX1FwWFIC7JoFDiXjo1sJOe57BZCLLnb9bWFwQBqoCC9iNQf3ciQlPiBXqfPihj1a0e7hXCax4VvOz73GGTceY31i1gf7ZfTElERbQXmpDTZrXA0RCTvw/+A1NAG5W3jl8a+hX X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 2, 2023 at 5:55 AM David Laight wrote: > > > It would just turn all kernel addresses into all ones, which is then > > guaranteed to fault. So no need for any conditional that never > > triggers in real life anyway. > > Are byte loads guaranteed to fault? Yeah, we don't map the highest address on x86-64. And we don't want to in the future either, because of how our error pointers work (ie if somebody misses an "IS_ERR()" check and uses an error pointer as a pointer, we want that to fault, rather than do random things). It's not a hard requirement architecturally (either hardware or software), and iirc on 32-bit we used to use the last virtual page for something, so maybe I'm missing some odd use on 64-bit too, but accessing the top-of-virtual address space on x86-64 should always cause a clear fault afaik. A byte access would always be a page fault, while a wrapping access might trigger a GP fault first (probably not - on 32-bit it would be a segment size violation, on 64-bit we've left those bad old days behind and I don't think wrapping matters either) > Presumably the fault handler already has the code to untag addresses. More importantly, the fault handler isn't in any critical path. By the time you've taken a page fault, the extra instructions to mask off any bits are entirely irrelevant. > It has to be said that I don't really see why tagging addresses is a > significant benefit unless the hardware checks than the PTE/TLB is > also set with the correct tag. You can certainly pair it with hardware support for checking the tag, but even without it, it can be a useful acceleration for doing software pointer tag checking without having to always add the extra code (and extra register pressure) to mask things off manually to dereference it. And traditionally, in various virtual machine environments, it's been used for hiding information about what the pointer _points_ to, without having to use up extra memory for some kind of type lookup. Old old LISP being the traditional case (not because of some "top byte ignore" flag, but simply because the address space was smaller than the word size). People did the same on the original m68k - and for the exact same reason. Of course, on m68k it was a horrible mistake that people still remember ("You're telling me 24 bits wasn't enough after all?") but it's a new day, and 64 bits is a _lot)_ more than 32 bits. The new world order of "56 bits is actually enough" is likely to remain true in a lot of environments for the foreseeable future - the people who already disagree tend to special, either because they want to use the virtual address bits for *other* things (ie sparse address spaces etc) or because they are doing globally addressable memory on truly large machines. A lot of "normal" use scenarios will be fundamentally limited by physics to "56 bits is a *lot*", and using high pointer address bits is unquestionably a good thing. So enforcing some hardware tag check is not always what you want, because while that is useful for *one* particular use case (ie the ARM64 MTE extension, and hw-tagged KASAN), and that may be the only particular use in some scenarios, other environments might use the top bits for other pointer information. Linus