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 CF02794A for ; Mon, 24 Aug 2015 19:00:17 +0000 (UTC) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F1451BD for ; Mon, 24 Aug 2015 19:00:16 +0000 (UTC) Received: by iodt126 with SMTP id t126so160552509iod.2 for ; Mon, 24 Aug 2015 12:00:16 -0700 (PDT) MIME-Version: 1.0 Sender: keescook@google.com In-Reply-To: References: Date: Mon, 24 Aug 2015 12:00:15 -0700 Message-ID: From: Kees Cook To: Thomas Gleixner Content-Type: text/plain; charset=UTF-8 Cc: Jiri Kosina , ksummit-discuss@lists.linuxfoundation.org, Emily Ratliff Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, Aug 24, 2015 at 11:52 AM, 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. Yeah, it can be a hard perspective shift to make. And shifting the thinking about the kernel itself to always operating in a compromised state makes thinking about how to protect it much easier. User space is trying to hurt us! :) -Kees -- Kees Cook Chrome OS Security