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 E62F4C77B7C for ; Fri, 12 May 2023 18:41:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 35599900019; Fri, 12 May 2023 14:41:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DEB86B00A9; Fri, 12 May 2023 14:41:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A5FB900019; Fri, 12 May 2023 14:41:59 -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 062856B00A8 for ; Fri, 12 May 2023 14:41:59 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B74261A1011 for ; Fri, 12 May 2023 18:41:58 +0000 (UTC) X-FDA: 80782472316.28.56C09FA Received: from out-37.mta1.migadu.com (out-37.mta1.migadu.com [95.215.58.37]) by imf01.hostedemail.com (Postfix) with ESMTP id 9CC0D40009 for ; Fri, 12 May 2023 18:41:55 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cIHho+Ff; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.37 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683916915; 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=iOnY8c/lkag14SwpbgN3+7P0+KsfhnCfHTsBvfxLgio=; b=ed00AuLutw4n3HReUSszvKtCfXce8PWeaT8yhihGB48Z9Fkl0vYSaqUhwIPux6ZdpsnW7W IKX0AtG2mly55mU2GjwXexonTBOLcCNTwnxLEyGXRegdIlIjV0rzput8KC5XPpw1RSDIJB nGJVd9LP6B+BklNw4gsngkEF3FpiUPc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683916915; a=rsa-sha256; cv=none; b=55s7HAdDdt3d7z9La7u9ts5u9kGjcXvz2e/7z/nONp23iH2rCp6MQ8Aagf7OhnIL4MgbN2 pkNWZKmgPpaSIvYkJMTpEpbDhjRnFyndii9lLFk5Hn6TK2coYOfAgvOsMAl0cKXH0151Dr XodgHWR66O5xQgkrFKMmFaI255shMAc= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cIHho+Ff; spf=pass (imf01.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.37 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Fri, 12 May 2023 14:41:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1683916913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=iOnY8c/lkag14SwpbgN3+7P0+KsfhnCfHTsBvfxLgio=; b=cIHho+FfHJMWMTsZ/N4RXcZep7VCfnvUNYdJrQllaDrmrotT2SUDGE/aHck2l6nZoZ0CbH 0Fkfdpcl1H8lNKNlg0uD5E1JTq7pzKxPky5aDLIUmKvPKEBSSRmvPWhrdW3Rg9i6PrJYJP T/Rx9juakd3xD/niy4bTd9Uj/lcX2I0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Kees Cook Cc: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202305111525.67001E5C4@keescook> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: wkkmyns4k3cco98wzmm8bwkssji56f13 X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 9CC0D40009 X-HE-Tag: 1683916915-70527 X-HE-Meta: U2FsdGVkX1+N4nv8esOmR0+Eee+UCwk/y9z5YpoN93+KBBx1Xn8crLP8VFe7EAPuu1yJHyMKcWK5sN69q/RtfltGbitpqT7tgJ//pIeAB50JRtceMD7VASHkM+oHhfvipm4fpxaCXiLU+lTUHUvetSYurvxiLk4w2wGLdHna2tk0D0mcotiyJnjfEikDmwK04B44s9bY03LNpTOE2RgrauACJqP/lPkoZXkXAg2vVfobJAswS5uOeritJ/n871Rh9mrpDxoQc5m1Sw451YQTSp85gKYCuOB3GWLFzb4ZKKY0w/waAMVA7V1ciV+ilLgToorsv3TRIaX+Lkk1WdsffdYWCozsUt/WuVTJg9o5ZkjwNYhmuchUsoGxukL+bSnLtXmA/rPNy1ew2EYh447o066EaDjQur9luzom5uTs4jaiRYGOjV4wP314U+STWydn5t7+48BWuZNIqj8VzQbWGFxoMrj32M48PnNsl4iMoyzO3bXy2g4sitfWnK0xCL0eE+ixYf0cHZS2bVyYE4FExdrdeCcNBN+bOql4pZ5EtOHWWkvYF77ZN68jdQuPvBIWOSsCx9UwL/APo/7791qYEI1YpitP2S0cjpTa4M2Tmk6Th2uS7dQvCW+no+tisxBXkR2zZvXUaGGrTZyDNOsmfRxP+OMbCfPc8vRHcmaXszYzD2HRSskqCfMktaVZYmHn1/+ovOKyj1sxIrIlC12uJdkzZh9DjXLgnNsY+pgqRohZsZY2J05V0h5dQuP/jdRCZ1vtgyExWz8h2vyLxl1V7TUvo3xJcFZ3VlsXeEeZaqHzILgTpq7eS6Wh7beqVgd3iyDCEFRHVvTf25gvBbjUJzADvkid/REfZOBnd0Bvsyk71pYO7lDimfhvNFUkyyoJq+IPBqgaSJnAVn6ldgzgDuYFtjkDg4nTy1qzPsgnC2DpD1MLi58rBQK5jANfldgSdNZQtsscjp9SQMIkcvi DmZt5fVV 2XYs2yrde/8X/ooT5zrOoVqJ2adSqZf6l6q/mDfm9gIqNmUN6g6YIcfcmM0I1tsSm7vp82yIK5yc++5/NRaE9GGgxxChiZVJ0+pcg9tQSg47FjofyWi85u8oKtSzNkM0DqfnrACFC+j2vi+kuG+d3v00D1+QaXpSb5zrNSXUbpsFINo+F/snnEgnd5D+if+yc4BzBaLfuTiKLPKw= 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 Thu, May 11, 2023 at 03:28:40PM -0700, Kees Cook wrote: > On Wed, May 10, 2023 at 03:05:48PM +0000, Johannes Thumshirn wrote: > > On 09.05.23 18:56, Kent Overstreet wrote: > > > +/** > > > + * vmalloc_exec - allocate virtually contiguous, executable memory > > > + * @size: allocation size > > > + * > > > + * Kernel-internal function to allocate enough pages to cover @size > > > + * the page level allocator and map them into contiguous and > > > + * executable kernel virtual space. > > > + * > > > + * For tight control over page level allocator and protection flags > > > + * use __vmalloc() instead. > > > + * > > > + * Return: pointer to the allocated memory or %NULL on error > > > + */ > > > +void *vmalloc_exec(unsigned long size, gfp_t gfp_mask) > > > +{ > > > + return __vmalloc_node_range(size, 1, VMALLOC_START, VMALLOC_END, > > > + gfp_mask, PAGE_KERNEL_EXEC, VM_FLUSH_RESET_PERMS, > > > + NUMA_NO_NODE, __builtin_return_address(0)); > > > +} > > > +EXPORT_SYMBOL_GPL(vmalloc_exec); > > > > Uh W+X memory reagions. > > The 90s called, they want their shellcode back. > > Just to clarify: the kernel must never create W+X memory regions. So, > no, do not reintroduce vmalloc_exec(). > > Dynamic code areas need to be constructed in a non-executable memory, > then switched to read-only and verified to still be what was expected, > and only then made executable. So if we're opening this up to the topic if what an acceptible API would look like - how hard is this requirement? The reason is that the functions we're constructing are only ~50 bytes, so we don't want to be burning a full page per function (particularly for the 64kb page architectures...) If we were to build an allocator for sub-page dynamically constructed code, we'd have to flip the whole page to W+X while copying in the new function. But, we could construct it in non executable memory and then hand it off to this new allocator to do the copy, which would also do the page permission flipping. It seem like this is something BPF might want eventually too, depending on average BPF program size...