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 39DC0EB64DC for ; Tue, 20 Jun 2023 20:43:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 78F918D0003; Tue, 20 Jun 2023 16:43:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7400F8D0001; Tue, 20 Jun 2023 16:43:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E0B38D0003; Tue, 20 Jun 2023 16:43:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4C8248D0001 for ; Tue, 20 Jun 2023 16:43:11 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 0FAA8405AD for ; Tue, 20 Jun 2023 20:43:11 +0000 (UTC) X-FDA: 80924300982.30.3831D3B Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id EB6302000D for ; Tue, 20 Jun 2023 20:43:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ze45L8Tv; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687293789; a=rsa-sha256; cv=none; b=B0Nr+cKmmK/mmBTAb0R4dcfsmPrFZmZ1TbpprnBchJ1PCY99au3e8hjXQ6DNm2XLWbvcYg n9iJvxbzqCxWadN2Uxmkmj0pAKb6c8KY38As4w7Vg5nu0pcQk0IR2rg8Mll894OysaPyZN Lmxx2ewHkkAK6gFOzDXyXCO5NtshJbw= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Ze45L8Tv; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687293789; 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=8jarQwxHT8yvhIQenywME8l9l7Ip5yj+cMcsI7OrpdQ=; b=IapzPbSZO73HJxz0MnAGhylTJ46uvRqR+GLZwUp6/NVbDeAecj8kyE69dEgT7Y4X3HRdOn ok2yczULacinYoBsLWZyA73igDdW+B2Pu0oHZ0rrq9VTbseLGifMGhM+Ch72FwKV7uVFeR 3G8/Wa9uyhdD6b3pj3vMV7VMigjGoOo= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id BD8FC611C6; Tue, 20 Jun 2023 20:43:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84D20C433CA; Tue, 20 Jun 2023 20:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687293787; bh=+GKm7AfWZk7imJmF+l1VZpt2mG2VQKVZcNY+CGDuwQk=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=Ze45L8Tvl9JFRVnMoGAzuTAAfQfxp3JkU9Eip0mvn+HFpj63t6plWQ9FiWP6ByhP6 qUK2977tv7T4S/PeC1C3OI0JBLGteL1tA3iYmItKuYW+I71iRIpjBZVzIEA9pGlVV+ kaQbdwzf91S93BSuxVLp7BtrnqWASs898jC2XXadwFDYAqagGz37DQbmKFQYUIk23u hXArqOY5gcpzmr7gjX53SjIAyCqEovqOQZmEFefKsoP7gkftnXFtJ7+nT61LesSgD7 FYTBUlkAqtpX6dFTuvlwfNB8Knms9OWNth0HprmHxqJJ+MR8iY5TSC9soKW/wpzYc3 OIqhrjp23nunw== Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailauth.nyi.internal (Postfix) with ESMTP id 60AC127C0054; Tue, 20 Jun 2023 16:43:05 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Tue, 20 Jun 2023 16:43:05 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgeefhedgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgesthdtredtreertdenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpedvveelvdeukedtuefhgeevvdeluefgteeggffggfegteehhfek tdffkeeiffetjeenucffohhmrghinhepghhouggsohhlthdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhguhidomhgvshhmthhp rghuthhhphgvrhhsohhnrghlihhthidqudduiedukeehieefvddqvdeifeduieeitdekqd hluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugidrlhhuthhordhush X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id D107931A0064; Tue, 20 Jun 2023 16:43:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-499-gf27bbf33e2-fm-20230619.001-gf27bbf33 Mime-Version: 1.0 Message-Id: In-Reply-To: <37d2378e-72de-e474-5e25-656b691384ba@intel.com> References: <20230509165657.1735798-1-kent.overstreet@linux.dev> <20230509165657.1735798-8-kent.overstreet@linux.dev> <20230619104717.3jvy77y3quou46u3@moria.home.lan> <20230619191740.2qmlza3inwycljih@moria.home.lan> <5ef2246b-9fe5-4206-acf0-0ce1f4469e6c@app.fastmail.com> <20230620180839.oodfav5cz234pph7@moria.home.lan> <37d2378e-72de-e474-5e25-656b691384ba@intel.com> Date: Tue, 20 Jun 2023 13:42:44 -0700 From: "Andy Lutomirski" To: "Dave Hansen" , "Kent Overstreet" Cc: "Mark Rutland" , "Linux Kernel Mailing List" , linux-fsdevel@vger.kernel.org, "linux-bcachefs@vger.kernel.org" , "Kent Overstreet" , "Andrew Morton" , "Uladzislau Rezki" , "hch@infradead.org" , linux-mm@kvack.org, "Kees Cook" , "the arch/x86 maintainers" Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EB6302000D X-Stat-Signature: 54symyxr67q4eimzscrp4qmye5ron6u5 X-HE-Tag: 1687293788-674305 X-HE-Meta: U2FsdGVkX1/IbTTlbkxVcAIMQfN7NIStk0SUXiuzCAjKRwIdjvBZIk8o+aMX2Ln54JBIoKL3JpBQMl/1SCw8J0xcevBwafcJFOK3SmdG5aHzg+XxdFTwh/LhLAOlHCU/p8cI3/tH9TsfnFIz/HWf8P1P4LwWohvCPohkpWs4oMe5ZJzcig8YC/shak69sxwLekQ86u4r/4hvnOS6C6k9K7pqPUsgbCu4x0s8mbNXy4fHtOX74SwHUrzIZTMDFSrdxSQiIIlVXWN0oxW61oP4sNZ2u5kq84mtdtEu+w4hTeFzqr0Ew49cGExBhFTasnpolPmlYDyL0AJIWkJsI8DkX0q0+t+YrgO8BhQZ24ckMx+IkNWpy0Jst+olI8qOJvuAEcvduxuAAl/hk4GsFsieCESXlFfVm3Fx7ICcxg89tkwCXWSaVIqJ5IuqLAw3YukgNm05juPO7drOGthR3hb/tLjsDZXnw1QC3wKKo2gQ2NvUdxIx8fx36pIDg8OzSYGHamCRdGJo9adhXKkk3gTqjuBdGIyCHRltqfo/XXpsvV1GLO+VdaYNU9p5honL9RTobFrHcPpccGS52IX3d/nkQfOv/zM2YH0Rgf3VE1fHOR+523FeUzByAhJ5Nn2F9dFYgM2c1Qr6cnYnj/CDWTvbpIUrcwPquJliPk22PgL7GQEGMuwBI9RhuuOK/6D1Bj0AtQEMmdLm+aHyBl/+m6b2WYj6j0y0HuHiicprtVe18E1h9ufxt6HEAZjZ1A86HLFV6sB93E4kldd/d4ZuxzJPKqqZgqsh7g5mhBu6m0IiS7lvyFnQGToQUhWliOM9ncC3Qpb6Z4EjDXcUkfiIz+SsQTLEcCCLjLKZzmUWQ+d74GxqoQGjJ9OaJrTB3a0VIIvcJLQgEcOYgPCYtK8Q2dmChf0SrECj3754MwuBgONqLBtqIzMefo1beVrp8QopSDZyPqhS2UWALu/zh9R6xP9 rWMBOP62 o2CfHW/T9yeTlnEIx4gGU6+5ahwB7Danpm0hB6EYsfyhlB95boSR0wVcZfmnHxx1Dtd+wK0xhfWEI/yIGYtCHlLEEZZXYMozbzo2WBNtQLnTvyRWglEPfB0dJ1uIrh8meoaqLHq33JMaof+Wv1WhBGhX16oOFtS8pRmZ4L19kJO8LkZqBuJ0kijgCnVZVLUZOx0Y6e64WB9njaNU0GsB1oMrua88nKyyJal5Hw1emrrcL7VtTZwxG3yclPW2U82tAy7KMVBylvsqqIGJ3bwRJsoJYZhQUXSIdZi+HOElV8AiDEe8syJ8Hcml/Y59tkY1+j+JYl3OoHB2N5MbQZmNVzp4dG97YvkIGCRwEkvLQ80ZcMdP5Hz2y01aiqbmzTrZw96nU9oP5n0FBNIznH0QDj9FGCsox2Wu/s9q0pXmWAbhjfQ5gnCGCS8b2qGa9VtVfCkIPrpzBlEvPCAQ8ry8DmjN5pba47bBEx2jYHH15bKNxUJM9EOkK9VEG+K7s/EjMqKrv 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: Hi all- On Tue, Jun 20, 2023, at 11:48 AM, Dave Hansen wrote: >>> No, I'm saying your concerns are baseless and too vague to >>> address. >> If you don't address them, the NAK will stand forever, or at least >> until a different group of people take over x86 maintainership. >> That's fine with me. > > I've got a specific concern: I don't see vmalloc_exec() used in this > series anywhere. I also don't see any of the actual assembly that's > being generated, or the glue code that's calling into the generated > assembly. > > I grepped around a bit in your git trees, but I also couldn't find it in > there. Any chance you could help a guy out and point us to some of the > specifics of this new, tiny JIT? > So I had a nice discussion with Kent on IRC, and, for the benefit of everyone else reading along, I *think* the JITted code can be replaced by a table-driven approach like this: typedef unsigned int u32; typedef unsigned long u64; struct uncompressed { u32 a; u32 b; u64 c; u64 d; u64 e; u64 f; }; struct bitblock { u64 source; u64 target; u64 mask; int shift; }; // out needs to be zeroed first void unpack(struct uncompressed *out, const u64 *in, const struct bitblock *blocks, int nblocks) { u64 *out_as_words = (u64*)out; for (int i = 0; i < nblocks; i++) { const struct bitblock *b; out_as_words[b->target] |= (in[b->source] & b->mask) << b->shift; } } void apply_offsets(struct uncompressed *out, const struct uncompressed *offsets) { out->a += offsets->a; out->b += offsets->b; out->c += offsets->c; out->d += offsets->d; out->e += offsets->e; out->f += offsets->f; } Which generates nice code: https://godbolt.org/z/3fEq37hf5 It would need spectre protection in two places, I think, because it's almost most certainly a great gadget if the attacker can speculatively control the 'blocks' table. This could be mitigated (I think) by hardcoding nblocks as 12 and by masking b->target. In contrast, the JIT approach needs a retpoline on each call, which could be more expensive than my entire function :) I haven't benchmarked them lately.