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 9F44AC4F for ; Sat, 21 Jan 2017 02:10:46 +0000 (UTC) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BB641133 for ; Sat, 21 Jan 2017 02:10:45 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id 8152D47A320 for ; Sat, 21 Jan 2017 02:47:14 +0100 (CET) Date: Fri, 20 Jan 2017 17:47:02 -0800 From: Josh Triplett To: Andy Lutomirski Message-ID: <20170121014702.nqpbthe63emb7jxv@jtriplet-mobl2.jf.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Josh Armour , Greg KH , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] security-related TODO items? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jan 20, 2017 at 04:14:25PM -0800, Andy Lutomirski wrote: > This is not easy at all, but: how about rewriting execve() so that the > actual binary format parsers run in user mode? I really like that idea. And not just the binary format parsers; everything except the "do what would happen on exec" transition within the kernel (the bits documented in execve(2) as changing/resetting on execve, other than those bits trivially doable in userspace). (One potential challenge: this still has to handle setuid binaries safely.) I can think of other syscalls where a userspace implementation would make sense, as well, if it can run with reasonable performance. For instance, imagine moving compatibility syscalls, x32 syscalls, or deprecated syscalls into userspace, such that if a process found a way to compromise that layer, it couldn't compromise any other process. - Josh Triplett