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 D2B6AC77B7F for ; Thu, 11 May 2023 05:55:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E34236B0072; Thu, 11 May 2023 01:55:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE4786B0074; Thu, 11 May 2023 01:55:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD2E66B0075; Thu, 11 May 2023 01:55:45 -0400 (EDT) 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 BDE786B0072 for ; Thu, 11 May 2023 01:55:45 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 267B71219DD for ; Thu, 11 May 2023 05:55:45 +0000 (UTC) X-FDA: 80776912650.30.0E742FE Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf26.hostedemail.com (Postfix) with ESMTP id DDA2E140061 for ; Thu, 11 May 2023 05:55:25 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=j0HanOY4; spf=pass (imf26.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683784526; 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=SMmV3TzaqHRTrXH6Q0nofDnJqnbSzTYjFsEZvKZ4z+8=; b=3l+DIz0DpGBcE7ZxLpdseRQhdr+6s0gm+PU1O7Ufe0ajfPH732weE4uNx5afvLg/MvijUD pGf06lVOFpJIr7yX0SZDLhkWOQPjIMK+xbJRzIgbaCE8Mjy0N158bjeq3zJWHQHBO+2v0K MOUa+R62OX3FM42QVjtI4Af2AiHwFBs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683784526; a=rsa-sha256; cv=none; b=3Wi8zlfxUo3UVlIHGh7eYWGlMmH+vZ4JiVbJDSTFB6mgIz7qzTlWo21ESi7vZjvyCCSEh3 N58T3OqzzoZlgF8kZMVrV8+a/G0ouReUZKvjKBLTr464sguulOHEeoPLuqOeeolq4lSzhU dY72+DIUH2z+/T0K0isxW3hWwE15aEE= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=fail ("headers rsa verify failed") header.d=mit.edu header.s=outgoing header.b=j0HanOY4; spf=pass (imf26.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu; dmarc=pass (policy=none) header.from=mit.edu Received: from letrec.thunk.org (h64-141-80-140.bigpipeinc.com [64.141.80.140] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 34B5XEbN029523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 May 2023 01:33:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1683783198; bh=SMmV3TzaqHRTrXH6Q0nofDnJqnbSzTYjFsEZvKZ4z+8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=j0HanOY4jf1J54zi0i0lwYZmgLq0/Ss5ILpuFT7MZBXheoGDM4ZR4KhI9GTbErwmm McYjxSg24VdxTJnvNpHfEOgY7MxjKA3ibaqz/9XLwbTrl/s6PygVJHF9OhxcSz2l+8 F4YqJEo2S5W9FnEmozQRSmKmBkYYZpS38T4Axq5yZpBG18V29DOCHbb6X+Hn0z9ZpS muw7Xmf+h2N8tt0ncXZ2V2IWwR8ZMBzFl4SpUAQwZOo5z3xa6FFkkcQE9LbtNuwa5X 2NyR3pQFe+1v43HP2jRX4X9XZKOswe2fS4BeCA8H0Nm/kVPADxGSmXjDJf4uhiVHDV Zu7MvmI+YvVHw== Received: by letrec.thunk.org (Postfix, from userid 15806) id 478D28C023E; Thu, 11 May 2023 01:33:12 -0400 (EDT) Date: Thu, 11 May 2023 01:33:12 -0400 From: "Theodore Ts'o" To: Kent Overstreet Cc: "Darrick J. Wong" , Lorenzo Stoakes , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org, Kent Overstreet , Andrew Morton , Uladzislau Rezki , linux-mm@kvack.org Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec Message-ID: References: <20230509165657.1735798-1-kent.overstreet@linux.dev> <20230509165657.1735798-8-kent.overstreet@linux.dev> <20230509214319.GA858791@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: DDA2E140061 X-Stat-Signature: 54jkejn6bod55xgozi43rprfwczos9he X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1683784525-224493 X-HE-Meta: U2FsdGVkX1+2+wvGlKplPAidEhL6uhYXhrlHkEQOtKAQwQd7O3bTNinKn+azNUM99CkWfvaha5ikYNyF/hlO878ZfGyUNjMPRvxHJ7dA2QlGs3cXm0q3fWH8tGniBLz5AegsbuEvaj0GaOt1id9kj0hp0mF6TCnF7UrjqIiC6w5onR5PjGZH0sQQ+li/hu4SeLYkeJwRwAS9TmBnRB8u9Gbvec7UmQwh0TK4O0RXyhVdej+UaOl0CLTiyXk8lI0KOmamn6fESQKMzEV5P3LUgOHKTsrbP6TxCvi5nlWdzSBJSh2xU8cwinX0bJ8rGExec2m2rCzUVhsh8ELWVvAOlHMcF07n/YwUWahVmJ9I191AzAOw4CmbyIYNTrv4DagAKyKy15OKhpCS1jjn+GhvqOqdA89zLZFbk5CLYdP5RNqm1rJT8IamT7npsDDg7w0WMCml98rqcHbApnvR4iz7Ub88hXmVDBOaQ8nmXLrxR2D6x76GoLmvt1VdiBr8ZZhEmwRwA0zwPpIHApEuRpg8feTjXs4EsL8Hn5VwxFpS6DHnlNhw5wMBA3Wom0WP75GSxww6rP7X9aeqX0w7U5bIefRF3USzjXUk6pfBRGPEOgw049YLqFnI/NCVekXfTfUPM/n5jXNw6wnAl7ej31mHKg+n1QyJWfDbeLqN4HXnaOGijyQfsU9V2paf76e74l8J2X2HxUQLcP0LFlZAcsykvSUs71/eFwH1inVQdwYPA90+iGnh43RgdoFErSwOkrNg9bfyYtkHwXdfLN7UPY5XFjyoxoutv1G3ZiZg7bWybspB84SpVsZLu2TSz0zsIZ5VKNZDGfDn/bkVvvqfn2mEekX6JljnLMa2Dcw5lqj/Llu69qPeuSRTZYB/tXU4D8tW4f4xfBbThLgBrON0YRWxiz2AFIzQnCQYWEc124Bgqt+Dyg9VdIBAEKbweEfSrRCl0nzjTUv+lQUdITo6dCs UKofJLXF oJCpn7vHExwZkUZL53mlDxwVBWPYI39U2kDc9XoqwZ6fST6CTo6mBaHNZ4K7V4jR5yzVRIdLNLGeQZuYS20GJkfXrL1wYo/lSTxDsKSWGjjIWUPGTTLXFMnNg+4LX+5Uunrf08SzrU1xzIrZQTMI2VsPIwDZ7rKBkbLR9lbF0DsHzXtGFfwRxJZUasGeg1suF9NRHAXvmEXXaSugHZ9wEfe91MwXczv2g2frUAWPzb6OP5kZgGMZhEO7+5iHCcZgVLH5fYRM1+DadpduIa89aJ/FRnhIsQivh4S5gDG45rrQ5AsJ79SDC9h/9g043vzycmBJXgeiUBNtwFFYyRJJWH9H1c0JmsEAydt2TtHQL1WiMOCWlkcy9SOJImC6wB5zjmaFv5YSYmI7kDlHS7ALG6D1MxKxxfcSm3l6TAlNaeWFpxJNb6ShVQBgCed87Tfj320KpNlvJM3mGsDmyfp+CrEG3PA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.426503, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, May 09, 2023 at 05:54:26PM -0400, Kent Overstreet wrote: > > I think it'd be much more practical to find some way of making > vmalloc_exec() more palatable. What are the exact concerns? Having a vmalloc_exec() function (whether it is not exported at all, or exported as a GPL symbol) makes it *much* easier for an exploit writer, since it's a super convenient gadget for use with Returned-oriented-programming[1] to create a writeable, executable space that could then be filled with arbitrary code of the exploit author's arbitrary desire. [1] https://en.wikipedia.org/wiki/Return-oriented_programming The other thing I'll note from examining the code generator, is that it appears that bcachefs *only* has support for x86_64. This brings me back to the days of my youth when all the world was a Vax[2]. :-) 10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short. [ This particular heresy bids fair to be replaced by ``All the world's a Sun'' or ``All the world's a 386'' (this latter being a particularly revolting invention of Satan), but the words apply to all such without limitation. Beware, in particular, of the subtle and terrible ``All the world's a 32-bit machine'', which is almost true today but shall cease to be so before thy resume grows too much longer.] [2] The Ten Commandments for C Programmers (Annotated Edition) https://www.lysator.liu.se/c/ten-commandments.html Seriously, does this mean that bcachefs won't work on Arm systems (arm32 or arm64)? Or Risc V systems? Or S/390's? Or Power architectuers? Or Itanium or PA-RISC systems? (OK, I really don't care all that much about those last two. :-) When people ask me why file systems are so hard to make enterprise ready, I tell them to recall the general advice given to people to write secure, robust systems: (a) avoid premature optimization, (b) avoid fine-grained, multi-threaded programming, as much as possible, because locking bugs are a b*tch, and (c) avoid unnecessary global state as much as possible. File systems tend to violate all of these precepts: (a) people chase benchmark optimizations to the exclusion of all else, because people have an unhealthy obsession with Phornix benchmark articles, (b) file systems tend to be inherently multi-threaded, with lots of locks, and (c) file systems are all about managing global state in the form of files, directories, etc. However, hiding a miniature architecture-specific compiler inside a file system seems to be a rather blatent example of "premature optimization". - Ted