From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DF13B2C for ; Thu, 21 Jul 2016 15:54:13 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8AF4022D for ; Thu, 21 Jul 2016 15:54:13 +0000 (UTC) Date: Thu, 21 Jul 2016 16:54:08 +0100 From: Mark Rutland To: "Eric W. Biederman" Message-ID: <20160721155407.GF20559@leverpostej> References: <87lh18i1d6.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lh18i1d6.fsf@x220.int.ebiederm.org> Cc: Jann Horn , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] kernel hardening / self-protection / whatever List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Jul 11, 2016 at 11:30:13AM -0500, Eric W. Biederman wrote: > Many kernel hardening features are perceived as having downsides affect > performance or code maintainability. Which quite frankly is a security > issue of another flavor because if something does not work well, and or > is not maintainable after a while it won't get used. In some cases (e.g. copy_{to,from}_user checks), I think that's indicative of the structure of the existing code, and there are existing opportunities for cleanup/simplification and/or unification regardless of particular hardening features. To some extent, it would be better if we could do more ground work making those areas more maintainable, rather than focussing solely on getting particular features in ASAP. Thanks, Mark.