Received: by 10.223.185.82 with SMTP id b18csp30727wrg; Thu, 8 Mar 2018 18:33:40 -0800 (PST) X-Google-Smtp-Source: AG47ELt9v1HNZezDgjkC3FtH0jQ60RzniPMcpjvXzE7oivFVrqEiAulzgeAQhtRWz7nnZi7w9j2W X-Received: by 10.98.144.146 with SMTP id q18mr28806885pfk.103.1520562820593; Thu, 08 Mar 2018 18:33:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520562820; cv=none; d=google.com; s=arc-20160816; b=zwUjO8YYNu5beSPfFrtwVQQW3Et25a55BnJDJAeEwJLNhqVSfrg0w20u+0mUUFVm6H dqtkJf/R3mQM15klu+yq0NGopncmVKaBRP3O5jVteBbayBVWxjJT19WaTBYGhrtGoc2M +jTS/UwHqaPqOGq3uR+1CiYkHdUdD6XMadAoQPXw5b14sSaXMVcnPsNLjxJohM+dSL36 FbOxKj+n6gkSnhito0aYDhz7AXBH3WTFlgZIpuYokRsKeQ+42qM6eWqTGSiML2aY4SBT aEOFVFpxqsfp6Clev6koSHn24ZnZIVoRwDojrHMKqUo8Es0m2cXnt91VSCyaVdLieXcf tYkQ== 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:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=CZrlhnv49WaC6INkrKwZqt1bqCUQwU6mi22jWi7kBTQ=; b=wJQ05azfy+2mVBVqCaRKioenW8QX81KcDiLHX0SnH2BwWlVpe396niO9tsuhBF/ind aZ4TOOR9704VreoQvV3GP0VRHtZST2eDcdiWjwsrN2/ElbZwLFKYRvtWvzD6a9n6Nf2d /00jj5l7PrP4zKIjhXNPIfygTU/Iv4Q1wqNbHcn+V4nU9/LYcK2FpWf7dZ3WuFzr+qRC jjYR+fwPEv1q9q8e5qngrGKLPN7SQYT7MHoWglhFMtRA/oiwNuhO+EU7Y8iwfqKQdptk wgJHt+gNTdggHwCMhJbTCxTOZdpVU1zuAc5mKak0+k7GZLgeXxO88FvkktCWXcF+0OV0 lZ8A== 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 h13si9689pgr.678.2018.03.08.18.33.25; Thu, 08 Mar 2018 18:33:40 -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; 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 S1751157AbeCICcA (ORCPT + 99 others); Thu, 8 Mar 2018 21:32:00 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:46172 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750896AbeCICb6 (ORCPT ); Thu, 8 Mar 2018 21:31:58 -0500 Received: from localhost (pool-173-77-163-229.nycmny.fios.verizon.net [173.77.163.229]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id B84DC142CF848; Thu, 8 Mar 2018 18:31:56 -0800 (PST) Date: Thu, 08 Mar 2018 21:31:53 -0500 (EST) Message-Id: <20180308.213153.2003279953084099668.davem@davemloft.net> To: luto@kernel.org Cc: alexei.starovoitov@gmail.com, keescook@chromium.org, ast@kernel.org, tixxdz@gmail.com, viro@zeniv.linux.org.uk, daniel@iogearbox.net, torvalds@linux-foundation.org, gregkh@linuxfoundation.org, mcgrof@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, linux-api@vger.kernel.org Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries From: David Miller In-Reply-To: References: <20180309012046.6kcivmzzkap3a4xc@ast-mbp> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 08 Mar 2018 18:31:57 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andy Lutomirski Date: Fri, 9 Mar 2018 02:12:24 +0000 > First, compile your user code and emit a staitc binary. Use objdump > fiddling or a trivial .S file to make that static binary into a > variable. Then write a tiny shim module like this: > > extern unsigned char __begin_user_code[], __end_user_code[]; > > int __init init_shim_module(void) > { > return call_umh_blob(__begin_user_code, __end_user_code - __begin_user_code); > } > > By itself, this is clearly a worse solution than yours, but it has two > benefits, one small and two big. The small benefit is that it is > completely invisible to userspace: the .ko file is a bona fide module. Anything you try to do which makes these binaries "special" is a huge negative. > The big benefits are: I don't see those things as benefits at all, and Alexei's scheme can easily be made to work in your benefit #1 case too. It's a user binary. It's shipped with the kernel and it's signed. If we can't trust that, we can't trust much else. And this whole container argument.. It's a mirage. Kernel modules are 1000 times worse, since they can access any container and any namespace they want.