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, URIBL_BLOCKED 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 0CB51CA9EC5 for ; Wed, 30 Oct 2019 15:35:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B744F205C9 for ; Wed, 30 Oct 2019 15:35:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="tR6noo5C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B744F205C9 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 55B146B0278; Wed, 30 Oct 2019 11:35:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50BCF6B0279; Wed, 30 Oct 2019 11:35:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F9C46B027C; Wed, 30 Oct 2019 11:35:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0100.hostedemail.com [216.40.44.100]) by kanga.kvack.org (Postfix) with ESMTP id 194D66B0278 for ; Wed, 30 Oct 2019 11:35:24 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 9B6A8181AEF1D for ; Wed, 30 Oct 2019 15:35:23 +0000 (UTC) X-FDA: 76100850126.04.nest96_69340ae8bd857 X-HE-Tag: nest96_69340ae8bd857 X-Filterd-Recvd-Size: 5293 Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 30 Oct 2019 15:35:22 +0000 (UTC) Received: by mail-lj1-f195.google.com with SMTP id v2so3191233lji.4 for ; Wed, 30 Oct 2019 08:35:22 -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=6/cUvxppfvco+q/svBW0l1eTrvr4r1OMCG7AkgiKpcQ=; b=tR6noo5CwOi34VQIokfGyMdP+tJf/ZPULHPz8KIcLua8ZoHBLlO50xCqeMHaAGvVQa 48WC0IzF8IxRv33JMgEH6NVNXDntgXn7Qbh44b6Itm/zy8iGjwULy02N0bndCfuE2mWn J5Gwpff3AsiQbdxaPgA4+tL1vptqqQI4FjSr8FVKo2VUEXTe05i7hepKReBSN4ewi9tv zbaqlMUmmjqzytwjIcNNu6xS9h9lWk0Eaj0NjvRt2/CJPLu+0YZNb2skTCtzBUyPYFNU 4LvGej/Mi9HNnkRrWKHopWrOtOHpFc32BVA/CVOOxGZuSTldPR3GNZh63N8HGJiB7fSn K3Pg== 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=6/cUvxppfvco+q/svBW0l1eTrvr4r1OMCG7AkgiKpcQ=; b=AnMtPYxbbzH/mJmmwKDX1QEobUwu3Iq1Gn0XwB64lxwRgkVO49Qu06LQnYN7R3uUkR SewWbQ9GWvjhU/S2422FU+V9L/tQ1v93pAHC2oUEqk2vigypbt2J6VhPN3SCKYqjZHhJ fCGunWnUmScZWg7TnAGNoGKVi9xllp0DnYAOZizQy8KIKGcCZvftv6gubSa1nLqk5I0a Vd6Vzpfz9CLR3/hkR+vlgsrGSpktLT9qFREeXIosQAg46YDRFLzE8q+W1l3ioB8XTTy+ 9pRGHqUK/REp+Bb8bf2b4wpO09dqrpB67nwTFiZjSc5iY7RvePoyldmAN27YorrJafMK amJw== X-Gm-Message-State: APjAAAXOx+rqCy91/pBAmfD0cYdbuV2Nb0n7D5zcWKUfPsF6dyrdCtM2 qt7rFk1kBHIAqi/UDBpVgo37lwfNEL0R7XtM2Mk= X-Google-Smtp-Source: APXvYqxBvl31pTcQQnHQbXcbxQLKZEYYjr+em5rKZ5EtZ+2iT0oglxx0fEQ8/RXMOehSCT8SBwLe+R0VTmgUsFSdHMc= X-Received: by 2002:a2e:2412:: with SMTP id k18mr217604ljk.243.1572449721198; Wed, 30 Oct 2019 08:35:21 -0700 (PDT) MIME-Version: 1.0 References: <1572171452-7958-1-git-send-email-rppt@kernel.org> <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> In-Reply-To: <20191030100418.GV4097@hirez.programming.kicks-ass.net> From: Alexei Starovoitov Date: Wed, 30 Oct 2019 08:35:09 -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 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. 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, 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.