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 40B748D7 for ; Mon, 11 Jul 2016 16:42:42 +0000 (UTC) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2023173 for ; Mon, 11 Jul 2016 16:42:41 +0000 (UTC) From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski References: Date: Mon, 11 Jul 2016 11:30:13 -0500 In-Reply-To: (Andy Lutomirski's message of "Sun, 10 Jul 2016 21:28:53 -0700") Message-ID: <87lh18i1d6.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain 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: , Andy Lutomirski writes: > Are there useful things to discuss in person about hardening? (I > don't want to bikeshed about the name at the kernel summit if we can > possibly avoid it.) > > Plausible sub-topics include: > > - "USERCOPY" hardening > > - Virtually mapped stacks (I'm hoping to have that in for x86 before > kernel summit...) > > - Refcount > > I don't how much of this really needs an in-person meeting, but maybe > some if it would benefit. Given the history of the previous work on which much of this kernel hardening work is inspired, I think it makes some sense to discuss what is needed to get various features ready for mainline. 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. Rarely are we in the situation where defense against attack is the most important thing that people who are deploying linux are worried about. Eric