Received: by 10.223.185.111 with SMTP id b44csp614577wrg; Fri, 9 Mar 2018 10:19:49 -0800 (PST) X-Google-Smtp-Source: AG47ELtqYi5GxJ1/qvzkc8hFo8dAtlk4NMKL/0SGCROjISLl8pWyZxsSFGIZ/liWApaFS3HOi4lm X-Received: by 10.101.88.15 with SMTP id g15mr24727397pgr.383.1520619589408; Fri, 09 Mar 2018 10:19:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520619589; cv=none; d=google.com; s=arc-20160816; b=O7lFYAG8m7eHZ9QnDLwzhToq8NCNUqBuuizGa73s+bUCZnJx7APE2VtT8r/jW60KTy ZNNZsG5+qMQ9wN+z6etCtG2MxhhG3yIauj3JLt4OoVvrnIBsBA2oLbkOtwNK0Ndm5dNU p7K1mpIE8YWAwJySrwBAuUNR4RAe1jJSOmO0nh15wdjdYsKFFjztUvnYYjNd8oHl7ZWA 7ye32aUgbFfqA8ACGLkBJhozGnd5b68eDSI86CYYkNQ0GwFwi+0d1mXtNLO4Y1IXlbxp eKVbRblABKkn5m0K5UGkVoDaFNscG2PlNN76SMA7ehDR5IehXEBC6rxtE8WGe3X4AmtM EBtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=e9VgYCPjWRnemEuMF5ngBagT5VYZgT2vvvATGDoizU0=; b=T1i5ox+36rVwrCO8bP/jWKIPJwH7imU0S6xL+PtyplAzz6s1Pk4eUrRC2p78jDGEIA TFGxNJ+s9/ikYSpUbZ5L0zOsbdQbIz2SnCQSq6uE67THAT3sQRfSN2cBh0yGHw8tmzn8 U7jXiQN7nO8n9wIgqwxQTmv/6ho3+HFlbmR0j7oeI2Ya7d2tEKhCesyCVRDFMMprRFXL oPCuL085/pJvZXUxGDJg0FN87ALFid6Euah5mzvjPDdGUFGXyjI4qV2Ras8y7c+TNZRq Bi0XHmaoCuWfwy+v3L5cbFptGxd97Hi0xHGgHKuCzV27dCOGzrDOsudqCEvITD/B9Rad h0Tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=JdCEpEvv; dkim=fail header.i=@linux-foundation.org header.s=google header.b=amZELCFF; 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 38-v6si1225647pln.397.2018.03.09.10.19.11; Fri, 09 Mar 2018 10:19:49 -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=JdCEpEvv; dkim=fail header.i=@linux-foundation.org header.s=google header.b=amZELCFF; 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 S1751349AbeCISRq (ORCPT + 99 others); Fri, 9 Mar 2018 13:17:46 -0500 Received: from mail-io0-f175.google.com ([209.85.223.175]:33267 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751166AbeCISRo (ORCPT ); Fri, 9 Mar 2018 13:17:44 -0500 Received: by mail-io0-f175.google.com with SMTP id f1so4507180iob.0; Fri, 09 Mar 2018 10:17:43 -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; bh=e9VgYCPjWRnemEuMF5ngBagT5VYZgT2vvvATGDoizU0=; b=JdCEpEvvimwDbbOkPuxYrlE+U5BNYllvEpwHSylwRPU8nGMNkmBbQu4EBFQ+cmUAKd CL89cIp/O84EROHm+BuDRjGq1Ii6qnoZIB2Vl4bjEd376fM8nA8OZ8Fy2yQX9eXoJKCQ 1J11Ek9SlUJU0kceDzQ5xhIOfbGog2LUOOT763jwzwQ+vkzxUOC3vVnuBjnH0Ola/wAq /A7KxGsm/3XGyimzUnmyxaJq5TmJmBtWJtMcWfcShQjTOcKmSVH43/ljNkbC3n5ji8Ti l7flrCQCKowR+f9Eq0e96at/rWyTGlPv5Rf73CWAbt6Opj6P20NwU8b/17bREF1Fy8Ty 3XpQ== 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; bh=e9VgYCPjWRnemEuMF5ngBagT5VYZgT2vvvATGDoizU0=; b=amZELCFFF/B7qbYGijj2w9Q+uxyhiDutY7XfU9qUv9oSZ4ZHvAJPKrMz2Vhzuhmdp5 lpr50XuOPNAFNsrB40+USFM5cnkbZBMAhvYb7GyzQ882xeQShqJ80570aHpINR36r0hW tuO/YYMtIw7KdqpFPMwNpTIaVMtsYKRuWrHl8= 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; bh=e9VgYCPjWRnemEuMF5ngBagT5VYZgT2vvvATGDoizU0=; b=LBLsDtMxFxFfxP59u9E1jGwZHdZ1Bz0QoVse+j0XUti/uBx2OuHjLulRh6fxbprPrq 30R1Ri7WN24rXJBG/1XvH/iLW7EU7pujnmNosFLhKMOKXEl1UYtFFeaWt0y5pdCtNG29 ESxAvfk7NJgw6mMbiJGdDoQ63W2CRs+vRRfYcO7lpAOxyBoy88uHogqAAt83sVmUzwI9 1yGPXag6UF1eDVtQYVP6Bh+x+uVCopN9Exl4Dt1Jn2Qxt0Iw1BnrhIxuoub9DAjc7QPk aX1wkHr7KDaHNCY2fGFTnmh4qcNm7UNGvXrKCvaBc7FYBSsxE3/4pctNomYUW7h7o75d Sq8g== X-Gm-Message-State: APf1xPB2UQFOKvUPS0j4t067ax+1vY0qgbfyXGhYPSrOYl9qmaq7wjne ySUCQBPD13NM4tJk3XCWNsIr1tTwEopPu0h/448= X-Received: by 10.107.10.155 with SMTP id 27mr38513436iok.259.1520619462986; Fri, 09 Mar 2018 10:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.221 with HTTP; Fri, 9 Mar 2018 10:17:42 -0800 (PST) In-Reply-To: <87478c51-59a7-f6ac-1fb2-f3ca2dcf658b@fb.com> References: <20180306013457.1955486-1-ast@kernel.org> <87478c51-59a7-f6ac-1fb2-f3ca2dcf658b@fb.com> From: Linus Torvalds Date: Fri, 9 Mar 2018 10:17:42 -0800 X-Google-Sender-Auth: VWvVETAnJPDbj4HFBZM7tjZVP3I Message-ID: Subject: Re: [PATCH net-next] modules: allow modprobe load regular elf binaries To: Alexei Starovoitov Cc: Andy Lutomirski , 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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 8, 2018 at 9:08 PM, Alexei Starovoitov wrote: > > there is not abi breakage and file cannot disappear from running task. > One cannot umount fs while file is still being used. I think that "cannot umount" part _is_ the ABI breakage that Andy is talking about. > Not only "read twice", but "read many". > If .text sections of elf that are not yet in memory can be modified > by malicious user, later they will be brought in with different code. > I think the easiest fix to tighten this "umh modules" to CAP_SYS_ADMIN. I don't think it actually fixes anything. It might just break things. For all we know, people run modprobe with CAP_SYS_MODULE only, since that is obviously the only capability it needs. 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. My gut feel is that the right direction to explore is: - consider the module loaded for the whole duration of the execve. So the execution is a *blocking* operation (and we get the correct exclusion semantics) - use deny_write_access() to make sure that we don't have active writers and cannot get them during the execve. The above mean that something that executes to load a new ebpf rule will work very well. But a "start and forget" will not work (although you can obviously do so with a internal fork/exec). Hmm? Linus