From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756881Ab2IUCbV (ORCPT ); Thu, 20 Sep 2012 22:31:21 -0400 Received: from tundra.namei.org ([65.99.196.166]:49492 "EHLO tundra.namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756751Ab2IUCbT (ORCPT ); Thu, 20 Sep 2012 22:31:19 -0400 Date: Fri, 21 Sep 2012 12:22:44 +1000 (EST) From: James Morris To: Kees Cook cc: linux-kernel@vger.kernel.org, Andrew Morton , Rusty Russell , Mimi Zohar , Serge Hallyn , Arnd Bergmann , James Morris , Al Viro , Eric Paris , Jiri Kosina , linux-security-module@vger.kernel.org Subject: Re: [PATCH 1/4] module: add syscall to load module from fd In-Reply-To: <1348179300-11653-1-git-send-email-keescook@chromium.org> Message-ID: References: <1348179300-11653-1-git-send-email-keescook@chromium.org> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 Sep 2012, Kees Cook wrote: > Earlier proposals for appending signatures to kernel modules would not be > useful in Chrome OS, since it would involve adding an additional set of > keys to our kernel and builds for no good reason: we already trust the > contents of our root filesystem. We don't need to verify those kernel > modules a second time. Having to do signature checking on module loading > would slow us down and be redundant. All we need to know is where a > module is coming from so we can say yes/no to loading it. Just out of interest, has anyone else expressed interest in using this feature? -- James Morris