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 1E9D5C77B7A for ; Tue, 16 May 2023 21:47:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A57E0900005; Tue, 16 May 2023 17:47:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A07A1900002; Tue, 16 May 2023 17:47:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CF1E900005; Tue, 16 May 2023 17:47:27 -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 7DD05900002 for ; Tue, 16 May 2023 17:47:27 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 495BD403FF for ; Tue, 16 May 2023 21:47:27 +0000 (UTC) X-FDA: 80797454934.03.79E5FFB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 41EEA40008 for ; Tue, 16 May 2023 21:47:24 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="jQsyxEv/"; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684273645; a=rsa-sha256; cv=none; b=Lo4I4VyK+8l4C6uKMWY4UDK/LqTdE32d38GMImNduyNa6ROH0vRdOlaMufsJ8ZF1euL1RA sH4UB374Q6DFP4iKBiu5LOtqgXSbumBbF75qQf9aV9pWFpVlIISHMX8Wg6bEl14NoADlUB RugRTWKv/64fhZHLugbNl15GNSX/+Zo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="jQsyxEv/"; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684273645; 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=RCVWP5n6K6Lz8z9J8Ai6uKS353zWFJSSAzmmvd1zqIs=; b=tn+Zk1Om9/1N/1hwDDAlZJA77rjggyU7V5sGyxjDj9SKK888Qrx3BZlGjk839aMzF4v2Wj w6uA/qhSX1G4gv1FxAHX7ln1Lz3mjv/sGKlnMhftt6779b4DHPDx6L3hDrZ+79aaTkt/YQ wzGvMR4zSQ/hJ/EnGg5ADuuqrIycZ2g= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=RCVWP5n6K6Lz8z9J8Ai6uKS353zWFJSSAzmmvd1zqIs=; b=jQsyxEv/DJGXrls9lt3TGGtEWt WuFts7yqMOf5gyWydkkSKxLYQHXNrlHzF7TQ3F7DjIEqAQNneOhFt7afCCK7ByTcp7XYaHQGWWIRy VJBECcQLadjtrDov24LH4TUxbuEfKpCJwl77Udyc4QK/eCvDZm542DtwjkojwH6HZPuD+GfbwkC7L T/+mPaFm0xQzAwJiPd6DiH/iEylw9JWjCJKsB95mwzcGihE33us1vI6EZ0TW2RQDxQwKQ1jgH7Bef ynhhNOJj/OWpkej/BrBnb6vKgffjM7AuV1DrkAHTooY20eeVhrJ+EauXx3dtP8hgJmY6GDplzDld8 ymR+uepg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pz2Vl-004aWL-6z; Tue, 16 May 2023 21:47:13 +0000 Date: Tue, 16 May 2023 22:47:13 +0100 From: Matthew Wilcox To: Kent Overstreet Cc: Kees Cook , Johannes Thumshirn , "linux-kernel@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-bcachefs@vger.kernel.org" , Kent Overstreet , Andrew Morton , Uladzislau Rezki , "hch@infradead.org" , "linux-mm@kvack.org" , "linux-hardening@vger.kernel.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> <3508afc0-6f03-a971-e716-999a7373951f@wdc.com> <202305111525.67001E5C4@keescook> <202305161401.F1E3ACFAC@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 41EEA40008 X-Stat-Signature: joobe5f7y6si9h5qtdbxa9119hbgoa8h X-HE-Tag: 1684273644-810418 X-HE-Meta: U2FsdGVkX18bgMzvKZs3Si6ckpY4Lnhu4zVQ8UXmVZLjnY07Ey5UTrQpHBQPIBnJkLxBaPwCI4cKu4BqC0c04Gn3d7e9uYPEXv5FF/fnmNYkQRyhoWJBrWrI7F29Equ6Qg60RncfqNnDpZZ7WxgN3apyW52PUwDgdn63ZrSMcHImTw1Kk8nfj/+vQlBi6bzXP6x3H5H4w7X5X7+5MLpfpRrxuo1V9Mo6ani35F2nyHLGP+Cy8/ucxUBgR1bU8E4YDNTTFl8V4c2tJPyY4Rn/0ad1qhIbZFjqoyn5ZmuR+oD3kBgk41rKu0F/9CfS5NhYMq38/pk3hNidwQvHrMZcwhuX/+4EhBM1BdJsbLNiMvGS/TMmxoKMXF9+bPa1qzWqyUb0b9Z5xBrpKUJypAmsuXME82U36JUo/aa1/amOVruIVlpCDPPqORSG2TvqyZUBa6LQ4/xYrYDh3oz8mx0LOSVi90ItBxc6Bw+uvb4V6F/ounPy9xLe5cHZzwZCAAIsyiQM3TdD5+s5kXXG7aYcVn9LCAOofS+g1c4u8NmFLEbkdwy7PkrLREgwkx1b3t+i4o2nSlAmqofg8m5QHjpXBn+jkqbbClX4WzzCXXLMk1IOh9WWd5HS0pqM++krizrO3pzdjGBrgjX8KKw7+Q4FvmUBUuwUotkXd3Yaq8Pc35j4mJdjdStjyP7blciYRUzRti3daQ60DWV1o0T3L4hQrE9r1o7CdIZrjzsOw2Ildt30xKxa/xMlRF+UGjwmYNgU1YI4jpJhupvx1lndY4YCpOAOZcaMC71/bHFBIsyj0REW1PIUR7HblTE6UJHIUkidxUf79MKmYpDcJ95K52Y084IYk1ah6YZv9i9ELVypke3AJz8fCPj78SyQnGrPz8hmJu7ml34MEvcLvq57UUorWY0totAtgDt5Nr/9wPj/xnbvMpvj2DbSBXUBJhf2tIip8pDyuE8FGEfqQ0ZvB/9 EVpx7Qdw f67TaA6N72P92hl/a3jgxHouKCf7lLPr5BReVzle8Tk4MlfmG8BgGLND8emXx7KREbF82Z4R0dnCA2+BEfxgxAuy9J74Sqd6+KswXcrAOVkrc6+hRL2UUJ18ryNfBHSNTCPb8FbEqIW93ix8xwln5CAWpQkUbQfJ0IcHzQSUQ9WU95XdAsyFyWcT9bhC8SWN8UM6qM37pQROyM7d/Y/F8nHMsFsgKE4d6Ilsg2Z49wTxr3JlRB2iP/S6SU/uHB7vkgY8wY8WCms6pTimLfP4ueIy+dAjYQXVFnozVhNMK6Ybu4lE= 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 Tue, May 16, 2023 at 05:20:33PM -0400, Kent Overstreet wrote: > On Tue, May 16, 2023 at 02:02:11PM -0700, Kees Cook wrote: > > For something that small, why not use the text_poke API? > > This looks like it's meant for patching existing kernel text, which > isn't what I want - I'm generating new functions on the fly, one per > btree node. > > I'm working up a new allocator - a (very simple) slab allocator where > you pass a buffer, and it gives you a copy of that buffer mapped > executable, but not writeable. > > It looks like we'll be able to convert bpf, kprobes, and ftrace > trampolines to it; it'll consolidate a fair amount of code (particularly > in bpf), and they won't have to burn a full page per allocation anymore. > > bpf has a neat trick where it maps the same page in two different > locations, one is the executable location and the other is the writeable > location - I'm stealing that. How does that avoid the problem of being able to construct an arbitrary gadget that somebody else will then execute? IOW, what bpf has done seems like it's working around & undoing the security improvements. I suppose it's an improvement that only the executable address is passed back to the caller, and not the writable address. > external api will be: > > void *jit_alloc(void *buf, size_t len, gfp_t gfp); > void jit_free(void *buf); > void jit_update(void *buf, void *new_code, size_t len); /* update an existing allocation */ >