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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 40F4ECA9EC5 for ; Wed, 30 Oct 2019 18:53:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E9B88204FD for ; Wed, 30 Oct 2019 18:53:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q9vziJ1/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9B88204FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 828926B0008; Wed, 30 Oct 2019 14:53:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D8416B000A; Wed, 30 Oct 2019 14:53:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6EE936B000C; Wed, 30 Oct 2019 14:53:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 4FE526B0008 for ; Wed, 30 Oct 2019 14:53:04 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id BD4EA4DD6 for ; Wed, 30 Oct 2019 18:53:03 +0000 (UTC) X-FDA: 76101348246.26.kite07_54da5b083a056 X-HE-Tag: kite07_54da5b083a056 X-Filterd-Recvd-Size: 6967 Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 18:53:02 +0000 (UTC) Received: by mail-lf1-f65.google.com with SMTP id y6so2418543lfj.2 for ; Wed, 30 Oct 2019 11:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jIFU1AD+72jsfU38zg+HIEX1tgHMzoBRVZFjXF6Qszg=; b=Q9vziJ1/ORLhXHfZpsb/YFqv39KVtjMCXdLKypqHHT41UNNR7zgxZOBMtOIOwPySeY ErHkeq8svkJ7UNobcsRtJNmzgzp9yMPO1NxZaLNtMH7ww390JjmeK2dEYNmLwtFRIkUJ KD18KfuGzTl4qxTmhiS/avUvKRQ6scFs367+y3YlxSgPWHXD81+dEFcPHyEXyOMXE7BA ZrDLXS2fYlEC471mXw16jciuH6XgRMqWoy7881+hW1HMa6Yv/+RoMEWEf9C6yt7da0P8 i0QPOUqpV5q/XwMeyiPCTXu3ZIo+9QXJPcSzMuaesfSOxCbApO5olMNz5Eoq117NbG6y xwqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jIFU1AD+72jsfU38zg+HIEX1tgHMzoBRVZFjXF6Qszg=; b=YE4DYOtlYJJrsy+TQXfBSqt+9yZULQM0FhwMNJzKVZKxVBWERc1TpzQud76SoMiMhU rtTjkxBue/zXVv3w/w7+jUD+eSLv6Uew/RsivbMbmJM2DnQMWb7mwmm4t1w3tvcglsLF /tC6uqchkA1PN520zjXk/lCzULWsLO8Cbod77BEt5z1aSmwbYnPG5fUuIe7G5yEuxTYJ N6Ht/OhuMd0dDjZVw0AQbln/pCNvQZ4xddSIzwwfq3X7bOoaG1VwQPJhoUWpQthrjknz up1pnY0L6z4nRmBZGeQ4Q1cc1vHAthu3CNjkM3Y8AAEFaMYHXpGNlSf5TenP2xgptwj7 gr1Q== X-Gm-Message-State: APjAAAX4WxrPcn2nFs+14Y+PYVFJA9phmY98qO9iAJpvfHUTOWaaPTHf gT1fcJhQ4PRnHUYT91CsQv7tIMSy8IXJoOzAs3I= X-Google-Smtp-Source: APXvYqxBfEmy8os1AtdFhBRsO9vTVp3EvrAAx5bsFNgkvZWHCGjDW2SxoShaVhp1kV88EsW3sfFhqSRLR7lWtyZ834k= X-Received: by 2002:a19:800a:: with SMTP id b10mr431161lfd.15.1572461581407; Wed, 30 Oct 2019 11:53:01 -0700 (PDT) MIME-Version: 1.0 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> <20191030183944.GV4114@hirez.programming.kicks-ass.net> In-Reply-To: <20191030183944.GV4114@hirez.programming.kicks-ass.net> From: Alexei Starovoitov Date: Wed, 30 Oct 2019 11:52:49 -0700 Message-ID: Subject: Re: [PATCH RFC] mm: add MAP_EXCLUSIVE to create exclusive user mappings To: Peter Zijlstra 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 Content-Type: text/plain; charset="UTF-8" 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 11:39 AM Peter Zijlstra wrote: > > 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. We keep so called "xlated" bytecode around for debugging. It's the one that is actually running. It was modified through several stages of the verifier before being runnable by interpreter. When folks debug stuff in production they want to see the whole thing. Both x86 asm and xlated bytecode. xlated bytecode also sanitized before it's returned back to user space. > > 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.. exactly. that's why RO bytecode was dubious to me from the beginning. For an attacker to write meaningful bytecode they need to know quite a few other kernel internal pointers. If an exploit can write into memory there are plenty of easier targets. > > 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. Sounds good to me. Happy to do that. Will add it to our todo list.