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 82C8D955 for ; Mon, 24 Aug 2015 19:00:03 +0000 (UTC) Received: from Galois.linutronix.de (www.linutronix.de [62.245.132.108]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03B74176 for ; Mon, 24 Aug 2015 19:00:02 +0000 (UTC) Date: Mon, 24 Aug 2015 20:59:34 +0200 (CEST) From: Thomas Gleixner To: Kees Cook In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Jiri Kosina , Emily Ratliff , ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 24 Aug 2015, Thomas Gleixner wrote: > On Mon, 24 Aug 2015, Kees Cook wrote: > > On Mon, Aug 24, 2015 at 4:56 AM, James Morris wrote: > > This is far from a comprehensive list, though. The biggest value, I > > think, would be in using KERNEXEC, UDEREF, USERCOPY, and the plugins > > for constification and integer overflow. > > There is another aspect. We need to make developers more aware of the > potential attack issues. I learned my lesson with the futex disaster > and since then I certainly look with a different set of eyes at user > space facing code. I doubt that we want that everyone experiences the > disaster himself (though that's a very enlightening experience), but > we should try to document incidents and the lessons learned from > them. Right now we just rely on those who are deep into the security > realm or the few people who learned it the hard way. A good way to start would be to actually force developers to document meticulously the possible states of user space variable(s) which influence the behaviour of the interface. That can be a mindboggling exercise depending on the complexity of the interface, but it helps both the implementer and the reviewer. Thanks, tglx