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 X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0F0ACA9EC5 for ; Wed, 30 Oct 2019 18:40:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 62C6620856 for ; Wed, 30 Oct 2019 18:40:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="PyViZqtU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 62C6620856 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 12F156B0007; Wed, 30 Oct 2019 14:40:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0DFB86B0008; Wed, 30 Oct 2019 14:40:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE9626B000A; Wed, 30 Oct 2019 14:40:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0212.hostedemail.com [216.40.44.212]) by kanga.kvack.org (Postfix) with ESMTP id C60AF6B0007 for ; Wed, 30 Oct 2019 14:40:05 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 581198126 for ; Wed, 30 Oct 2019 18:40:05 +0000 (UTC) X-FDA: 76101315570.21.kite17_7508b7e2ebe0d X-HE-Tag: kite17_7508b7e2ebe0d X-Filterd-Recvd-Size: 5843 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 18:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5yjTD0vSgrB/yBE3DW3WbNpFuPl1Y2o6+3IHmE5qv2E=; b=PyViZqtUR4cuRQwG7Cbsa+m62 o14pLDdczzOHm7K8vK7BdPRpMPrAC1MoCCCEIGrwBTwSFZ7aZdbjUKSkjnzx9mQxplTJBaEHS20q0 smnQU4y8FuEsVpPy1Nf1fdSSBxK1MsB+rBgII5iKsMUofCPK4lp6KMfe+rbEL5Y63Uv1qWT+3tsxg hoH+cdZPw0sXOphLTE4d6UMoYIiOxBf6PsUrDTuboxHS7H20Kb7OMA69rnz+ETqsl2vxqpWNVCnZ/ AbZLh0GGc9H6P9KEeU4dXjhyImYQEWMUOPmGdYRdSWW9cV2/FRAWq/DZ/BsDxAhhxT24oQ6nTVDzi SI4x9Xnvw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1iPssl-0001sb-7n; Wed, 30 Oct 2019 18:39:47 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 490D330610C; Wed, 30 Oct 2019 19:38:43 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 9261129AB4E95; Wed, 30 Oct 2019 19:39:44 +0100 (CET) Date: Wed, 30 Oct 2019 19:39:44 +0100 From: Peter Zijlstra To: Alexei Starovoitov Cc: "Edgecombe, Rick P" , "adobriyan@gmail.com" , "linux-kernel@vger.kernel.org" , "rppt@kernel.org" , "rostedt@goodmis.org" , "jejb@linux.ibm.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" , "linux-api@vger.kernel.org" , "x86@kernel.org" , "akpm@linux-foundation.org" , "hpa@zytor.com" , "mingo@redhat.com" , "luto@kernel.org" , "kirill@shutemov.name" , "bp@alien8.de" , "rppt@linux.ibm.com" , "arnd@arndb.de" , Daniel Borkmann , bpf Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings Message-ID: <20191030183944.GV4114@hirez.programming.kicks-ass.net> References: <1572171452-7958-2-git-send-email-rppt@kernel.org> <20191028123124.ogkk5ogjlamvwc2s@box> <20191028130018.GA7192@rapoport-lnx> <20191028131623.zwuwguhm4v4s5imh@box> <20191028135521.GB4097@hirez.programming.kicks-ass.net> <0a35765f7412937c1775daa05177b20113760aee.camel@intel.com> <20191028210052.GM4643@worktop.programming.kicks-ass.net> <69c57f7fa9a1be145827673b37beff155a3adc3c.camel@intel.com> <20191030100418.GV4097@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) 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 Wed, Oct 30, 2019 at 08:35:09AM -0700, Alexei Starovoitov wrote: > On Wed, Oct 30, 2019 at 3:06 AM Peter Zijlstra wrote: > > > > On Tue, Oct 29, 2019 at 05:27:43PM +0000, Edgecombe, Rick P wrote: > > > On Mon, 2019-10-28 at 22:00 +0100, Peter Zijlstra wrote: > > > > > > That should be limited to the module range. Random data maps could > > > > shatter the world. > > > > > > BPF has one vmalloc space allocation for the byte code and one for the module > > > space allocation for the JIT. Both get RO also set on the direct map alias of > > > the pages, and reset RW when freed. > > > > Argh, I didn't know they mapped the bytecode RO; why does it do that? It > > can throw out the bytecode once it's JIT'ed. > > because of endless security "concerns" that some folks had. > Like what if something can exploit another bug in the kernel > and modify bytecode that was already verified > then interpreter will execute that modified bytecode. But when it's JIT'ed the bytecode is no longer of relevance, right? So any scenario with a JIT on can then toss the bytecode and certainly doesn't need to map it RO. > Sort of similar reasoning why .text is read-only. > I think it's not a realistic attack, but I didn't bother to argue back then. > The mere presence of interpreter itself is a real security concern. > People that care about speculation attacks should > have CONFIG_BPF_JIT_ALWAYS_ON=y, This isn't about speculation attacks, it is about breaking buffer limits and being able to write to memory. And in that respect being able to change the current task state (write it's effective PID to 0) is much simpler than writing to text or bytecode, but if you cannot reach/find the task struct but can reach/find text.. > so modifying bytecode via another exploit will be pointless. > Getting rid of RO for bytecode will save a ton of memory too, > since we won't need to allocate full page for each small programs. So I'm thinking we can get rid of that for any scenario that has the JIT enabled -- not only JIT_ALWAYS_ON.