Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757856AbcK3O2B (ORCPT ); Wed, 30 Nov 2016 09:28:01 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:57276 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757362AbcK3O1y (ORCPT ); Wed, 30 Nov 2016 09:27:54 -0500 Date: Wed, 30 Nov 2016 14:27:24 +0000 From: One Thousand Gnomes To: Ard Biesheuvel Cc: David Howells , keyrings@vger.kernel.org, Matthew Garrett , linux-security-module , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 00/16] Kernel lockdown Message-ID: <20161130142724.1da771d0@lxorguk.ukuu.org.uk> In-Reply-To: References: <147933283664.19316.12454053022687659937.stgit@warthog.procyon.org.uk> <20161116222731.563fb85e@lxorguk.ukuu.org.uk> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1055 Lines: 24 > This applies equally to the kernel command line, and given that we > cannot authenticate it, we should whitelist params that we know to be > safe, and filter out all others. A similar concern exists for the > device tree on ARM/arm64, and we already disable the DTB loader in the > UEFI stub if secure boot is enabled. Or you sign the boot command line. > > Without that at least fixed I don't see the point in merging this. Either > > we don't do it (which given the level of security the current Linux > > kernel provides, and also all the golden key messups from elsewhere might > > be the honest approach), or at least try and do the job right. > > > > Less security is better than fake security. If you've got less security > > your take appropriate precautions. If you rely on fake security you don't. > > > > In general, I think kernel hardening is an important topic It is - so pushing something with known trivial holes isn't a useful way to do this. The module parameter hole needs to be addressed before this is fit for upstream. Alan