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.6 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 60D50C432C0 for ; Mon, 2 Dec 2019 16:20:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32EDD20833 for ; Mon, 2 Dec 2019 16:20:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="J4Q6ICfC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727599AbfLBQUA (ORCPT ); Mon, 2 Dec 2019 11:20:00 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:38494 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727484AbfLBQUA (ORCPT ); Mon, 2 Dec 2019 11:20:00 -0500 Received: by mail-lj1-f195.google.com with SMTP id k8so100180ljh.5; Mon, 02 Dec 2019 08:19:57 -0800 (PST) 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=HGcdF9VVAZCUdbTM3FRA/f2Jg2OzxmwCb3WDeSg01uA=; b=J4Q6ICfCXHjGa1mbOshuV0kuoj5iUFSJKHL9Q8Mi7UJC3Hfrr7dJ6AgrT/C7NgwgeI 1+7Dy3n73NyqgwgJgig6OH3dLZp/alupHshr0VbpkyNhC1xP+OOxSTQgo6kc6nP2vUBP nw1Nxvp+ZEpjekEc96NkXxJHokxE9ISYyoEQxn/ib+TGXmeSNrS6hRwkP2myDUlfcBwD bm9NirAqgfJzk/nIJ152Z7LhIsrPguVZOHkh1h+6YkGXed+4YbQVHbV2LEupmhNLpixY iJVL7d2zCpSNUJAAoJ4N0OIm/tdqzY2MsqtkNAJyMiuE9Yr5Ksf+x2KrEGoEznEGw2id wVtw== 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=HGcdF9VVAZCUdbTM3FRA/f2Jg2OzxmwCb3WDeSg01uA=; b=IwwsQ0lfJP8uttyT38SkR0wMh2jsR0puKqqZX70ZXPAai40dPW73/U7XDwrvF5Kh60 bagSFI7DKLwC1XqmjqIEK1QNFTtx/zNHUtcwpWIzZGcIS8fU3b8s3CRy2QmM8RKwlSpy soJIKi3yFGkNx1dbsA3TQNqKoJXW5mG3KMxRx//9hqcNkSXSSPmdYyUAPmNsPFA8GXCG EmyChv7JXfVKKwRP1OfHtMuudGPkFtDflt7RXwYZuZfIztJuvs/8A2Ykh1hlVnFfaCHe 8HVmcuW284quy7pj8WMscKMMrnHgW0H5w7cAd0syD08zPIIwlpPPiP2xHKYUdNEDAbfO Pt4A== X-Gm-Message-State: APjAAAWQryVU7tcUZVcwqTjzXMvn4Y4Kkgh6My7TcwMvkicwxj0phHr1 N8ez9nAtl1azloZiyzomd5zgzwZoh67bJuj8PIBXqg== X-Google-Smtp-Source: APXvYqxsifR7qs0VyP/hfXwyl8i1EH5mCES+VRxeCmY6i6+MPx5smYQkoH0ZJMSp/dUO3l5B/1Mb9Pox43Xd3ChjKKA= X-Received: by 2002:a2e:8508:: with SMTP id j8mr46640457lji.136.1575303597040; Mon, 02 Dec 2019 08:19:57 -0800 (PST) MIME-Version: 1.0 References: <20191129222911.3710-1-daniel@iogearbox.net> <10d4c87c-3d53-2dbf-d8c0-8b36863fec60@iogearbox.net> <20191202083006.GJ2844@hirez.programming.kicks-ass.net> <20191202091716.GA30232@localhost.localdomain> In-Reply-To: <20191202091716.GA30232@localhost.localdomain> From: Alexei Starovoitov Date: Mon, 2 Dec 2019 08:19:45 -0800 Message-ID: Subject: Re: [PATCH bpf] bpf: avoid setting bpf insns pages read-only when prog is jited To: Daniel Borkmann Cc: Peter Zijlstra , Eric Dumazet , Network Development , bpf , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Dec 2, 2019 at 1:17 AM Daniel Borkmann wrote: > > On Mon, Dec 02, 2019 at 09:30:06AM +0100, Peter Zijlstra wrote: > > On Sun, Dec 01, 2019 at 06:49:32PM -0800, Eric Dumazet wrote: > > > > > Thanks for the link ! > > > > > > Having RO protection as a debug feature would be useful. > > > > > > I believe we have CONFIG_STRICT_MODULE_RWX (and CONFIG_STRICT_KERNEL_RWX) for that already. > > > > > > Or are we saying we also want to get rid of them ? > > > > No, in fact I'm working on making that stronger. We currently still have > > a few cases that violate the W^X rule. > > > > The thing is, when the BPF stuff is JIT'ed, the actual BPF instruction > > page is not actually executed at all, so making it RO serves no purpose, > > other than to fragment the direct map. > > Yes exactly, in that case it is only used for dumping the BPF insns back > to user space and therefore no need at all to set it RO. (The JITed image > however *is* set as RO. - Perhaps there was some confusion given your > earlier question.) May be we should also flip the default to net.core.bpf_jit_enable=1 for x86-64 ? and may be arm64 ? These two JITs are well tested and maintained.