Received: by 10.213.65.68 with SMTP id h4csp8104imn; Mon, 12 Mar 2018 05:03:38 -0700 (PDT) X-Google-Smtp-Source: AG47ELsU3GVB8Bw3aPJynuhSYMLCxyKCiNf/WqWBsdOSKaVE0sTl29R2FQ4cxJ/Nsy2XOAQB5XV6 X-Received: by 10.98.75.129 with SMTP id d1mr7795636pfj.19.1520856218564; Mon, 12 Mar 2018 05:03:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520856218; cv=none; d=google.com; s=arc-20160816; b=Ybcg0DSCuWGf2QvUqN6bMOg5tJEThSprh9O/9er70a9L34qXbGgKuvESLTkti1zKhY ehTtoDqlQARklHyJNfLQH1aIqL3FZSY93hYrBpg6omqnC4CDKLa7zFgFrsu51HqgPVj1 WiCMz8QVqywG29+nMoyfHAkuZ/SLdMLdo3eJ/B/86wISNDiEQoxUcFoeV08fMf/C/y29 npZJTRM80OvFysRquB3yxao1vbuAXCibkj+37du+djBON9sfwebFgad6Yq5bAT7X1rmv 71KCETIdXcBwyyXPrn8TisKICTk/Nu3/o0PbVPxpmzQfWHE4657yTRm5j7qYOAwAseXa kzdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=KioqapZGwB8AVOA7Jdt1rxD+mNljkAIugFAV8bPdpnY=; b=y4igmF9HFX0++c4AXKKhKGeqVWtAS3/iDvoklsSkx4pRgHUJu7piGnroc01PxI7+gn Tcly8GcDi6EYBOrC7NHwhfpAmGDprbt2vmJQ/BMZ2Wnr7iqBuiqNTSMPYzgVPGQeJyYN KFRGHOtEeI8zjiTaCNsmUZbHKloLfC+GqO1zNFZv7Tfq7vTUweO2q6mgXcrQSeNmWrOy YgHXyTXrsh/u/7H0/NvXvMvkgwo3iAatneXpBiRDczWTz+HNer7mHrs2CyHFASH0cOeP rgnDGoaK4VgmOZfPyPoCMhCJsW2tfpUuiVkCxkq9XyZhJ8BtsM/01GbYsqmQT9hOIG/e eFJw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si5665626pff.68.2018.03.12.05.03.22; Mon, 12 Mar 2018 05:03:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751281AbeCLMCN (ORCPT + 99 others); Mon, 12 Mar 2018 08:02:13 -0400 Received: from dispatch1-us1.ppe-hosted.com ([148.163.129.52]:47026 "EHLO dispatch1-us1.ppe-hosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750752AbeCLMCL (ORCPT ); Mon, 12 Mar 2018 08:02:11 -0400 X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 045E6800076; Mon, 12 Mar 2018 12:02:09 +0000 (UTC) Received: from ec-desktop.uk.solarflarecom.com (10.17.20.45) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 12 Mar 2018 05:02:05 -0700 Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries To: Alexei Starovoitov , Linus Torvalds , Kees Cook CC: David Miller , Andy Lutomirski , Alexei Starovoitov , Djalal Harouni , Al Viro , Daniel Borkmann , Greg KH , "Luis R. Rodriguez" , Network Development , LKML , kernel-team , Linux API References: <87478c51-59a7-f6ac-1fb2-f3ca2dcf658b@fb.com> <20180309.133509.1275903267249306409.davem@davemloft.net> <77cdc9f5-b51c-a18d-5422-763cc4e76279@fb.com> From: Edward Cree Message-ID: <30db1e8e-8eb4-5072-8360-6cafe26db113@solarflare.com> Date: Mon, 12 Mar 2018 12:02:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <77cdc9f5-b51c-a18d-5422-763cc4e76279@fb.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Originating-IP: [10.17.20.45] X-MDID: 1520856131-hvWAqeJP+ngV Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/03/18 18:58, Alexei Starovoitov wrote: > It's not waiting for the whole thing, because once bpfilter starts it > stays running/sleeping because it's stateful. So, this has been bugging me a bit. If bpfilter takes a signal and crashes, all that state goes away. Does that mean your iptables/netfilter config just got forgotten and next  time you run iptables it disappears, so you have to re-apply it all again? > It needs normal > malloc-ed memory to keep the state of iptable->bpf translation that > it will use later during subsequent translation calls. > Theoretically it can use bpf maps pinned in kernel memory to keep > this state, but then it's non-swappable. It's better to keep bpfilter > state in its own user memory. Perhaps the state should live in swappable kernel memory (e.g. a tmpfs  thing, which bpfilter could access through a mount).  It'd be read-only  to userspace, listing the existing rules (in untranslated form), and be  updated to reflect the new rule after bpfilter has supplied the updated  translation. Then bpfilter can cache things if it wants, but the kernel remains the  ultimate arbiter of the state and maintains it over a bpfilter crash. Sound reasonable? -Ed