Received: by 10.223.185.111 with SMTP id b44csp644468wrg; Fri, 9 Mar 2018 10:54:52 -0800 (PST) X-Google-Smtp-Source: AG47ELt34zYeI6NCRcBeKFqAP0jcWpaelkFdTn1t7IMLqs7R2/c+PGgPDwPmYGBjoiqO5gGRWVIy X-Received: by 10.101.64.194 with SMTP id u2mr25284862pgp.280.1520621692816; Fri, 09 Mar 2018 10:54:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520621692; cv=none; d=google.com; s=arc-20160816; b=eZ3ix94+Alb9yGM1YVBzgojlaSjhNmrgaM5OwyQl0790oXOepXHOdOZFERty424+z5 gS9RhnWSD1OwYGyWlwneJRzFnqb7rcCM50bKubpzmfnUvs6e5fh7ZpIU1aM5JB3EPrMY U0YZ2j+oRdhUKEbqC+n3ZYcp/Gw0E8R6Y1z9aNJSOfJYU9qbSi8bIScoEPDo8dYBYO7U rNqjBlbFCzlxsmDSFD/LK46VGSIgva57d/GlGT2V0CqJHkHswTM9QRezT6S5zKc7RZDe vVf6T69p7EVfJLvadfoC2XfPUphriAenX6Fho6OaV00CVw1PO/bV0/MONZwZSyUlEOfx oCFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:dkim-signature:arc-authentication-results; bh=EYSYJHfP47Y2sI7qNgVLYnuPa21XmnosSpXHvKLEaXU=; b=lDT0m6TLeX+mrWxpX+IwZ8kf1DVUh3qik0nsRimKBao7H9t6loUjit8KlmJ1O7FA61 A4vdGZYu3zCidaWWfee2OjfhYyli4ZEpB9b/YacVT1I+CpdHOQ0N8cpS74ZAN/s1S8UY GRf5XU77SCin6VG5U6uljK8K98cRJnDTT74PFFmdmttCNLH3PJvf6ZlPCuSlu76tj7zu lPEdIF1kh5TmAQ21ln5EcSJhgBTbGkFHQaWHAI5uh5OTbPi2A1TqgSx+xZPk6O/G9eSu Gt3pr8nKcXbq4n90n2QY0U/97oSVipp8de2uRIRN98hvFz6DZRxxLWxwSEKWHxQqnOmK iSjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=nxJs2EeF; dkim=fail header.i=@linux-foundation.org header.s=google header.b=EcK3yELX; 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 s13-v6si284750plq.178.2018.03.09.10.54.37; Fri, 09 Mar 2018 10:54:52 -0800 (PST) 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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=nxJs2EeF; dkim=fail header.i=@linux-foundation.org header.s=google header.b=EcK3yELX; 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 S932437AbeCISxt (ORCPT + 99 others); Fri, 9 Mar 2018 13:53:49 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:56179 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932072AbeCISxq (ORCPT ); Fri, 9 Mar 2018 13:53:46 -0500 Received: by mail-it0-f65.google.com with SMTP id n136so3863689itg.5; Fri, 09 Mar 2018 10:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EYSYJHfP47Y2sI7qNgVLYnuPa21XmnosSpXHvKLEaXU=; b=nxJs2EeFDE2jrhfPijHedEOorQFaMq3oSxwlxnIOcCBe+u+3mKHiqKiuCb1o9829Ba L6yQ7vt3IR58LZEkgHlVqqGP5XL8nGR3+396cRVPP1bhWE2LR5FnfekZcDPUCWMP+w87 ruC68fKurPa9y8ybucBzq6ascA3fDb4o4S++XyyQFksBqwY80DiFFXERHgS+K7YVGHhW MUEYSQr1Gb9FR196kgq0yanAghnEehabi50LlA0s40E09ohmGF9i9WUxd0lLr6bpV0QY oQxcKstP/uvxJcKeJ+NPEYIf6gFmYKOqQYrU3sEr114KI0YxR2jgx5Od3BtcfvcaUTnB VArw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=EYSYJHfP47Y2sI7qNgVLYnuPa21XmnosSpXHvKLEaXU=; b=EcK3yELXXTvmmdojIRQmk28jiAZGy+gn7w+t71Y8IQXiNAMF22krhUlAVTrELHDIc+ az0OpFP8zgyU+D2j25+9G2fgyc9jfFLjdiY7Yz4VlHgqdTFcSCvjaV0wa4wQGcpmOhE1 p+y1nW79kfOVWvEIWsas8+HHGFZPlxSvUc7iU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=EYSYJHfP47Y2sI7qNgVLYnuPa21XmnosSpXHvKLEaXU=; b=dj1cE7Eh07HNnMhNP9npEngUzw0DtMKi9C6/XtZEScFIL3Woobciq2Z9/zviDjz6kU BVavkYYfhZ0Op4eYhUxJOoSb9KlVmPqMmVWtExbL7SqsXkW7rllz5H9XR1PX7uTwd1V9 M3u5YZVue3mNVoYLCFeJ/KwmYFF6E2usfr3k3ZLyyYGTOkdijsFHs1c4T1oYmcicWSQo 6ADCwqSNQSStj/9gNFK2NCudqRpGIhymrjQjxxSZs74yGa7D8fSOPQwxze0qz5Dm8YPn NX77+3D3urML2LQiPSyM1fhKXU5E6etssMxkNmqlpjzR4QeVsa25yZmP0rMGt61cdIS3 jxTw== X-Gm-Message-State: AElRT7GXFTarShI4mwG/R/Ypt8oj/ZejYOFu9adRPEFkhKI58HMoz4hR Hf1vZFs2GIOG7sF2zJBAHqdlKYzsgEyXPz1lN2E= X-Received: by 2002:a24:fec7:: with SMTP id w190-v6mr4936244ith.108.1520621625814; Fri, 09 Mar 2018 10:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Fri, 9 Mar 2018 10:53:45 -0800 (PST) In-Reply-To: References: <20180306013457.1955486-1-ast@kernel.org> <87478c51-59a7-f6ac-1fb2-f3ca2dcf658b@fb.com> From: Linus Torvalds Date: Fri, 9 Mar 2018 10:53:45 -0800 X-Google-Sender-Auth: asthy-fRQ9qU4vrMQddzQ8AWMRs Message-ID: Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries To: Andy Lutomirski Cc: Alexei Starovoitov , Kees Cook , Alexei Starovoitov , Djalal Harouni , Al Viro , "David S. Miller" , Daniel Borkmann , Greg KH , "Luis R. Rodriguez" , Network Development , LKML , kernel-team , Linux API Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 9, 2018 at 10:48 AM, Andy Lutomirski wrot= e: >> On Mar 9, 2018, at 10:17 AM, Linus Torvalds wrote: >> >> Hmm. I wish we had an "execute blob" model, but we really don't, and >> it would be hard/impossible to do without pinning the pages in memory. >> > > Why so hard? We can already execute a struct file for execveat, and Alex= ei already has this working for umh. > Surely we can make an immutable (as in even root can=E2=80=99t write it) = kernel-internal tmpfs file, execveat it, then unlink it. And what do you think that does? It pins the memory for the whole time. As a *copy* of the original file. Anyway, see my other suggestion that makes this all irrelevant. Just wait synchronously (until the exit), and just use deny_write_access(). The "synchronous wait" means that you don't have the semantic change (and really., it's *required* anyway for the whole mutual exclusion against another thread racing to load the same module), and the deny_write_access() means that we don't neeed to make another copy. Linus