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 C1E85C96 for ; Sat, 21 Jan 2017 01:10:42 +0000 (UTC) Received: from mail-vk0-f65.google.com (mail-vk0-f65.google.com [209.85.213.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 093D4210 for ; Sat, 21 Jan 2017 01:10:41 +0000 (UTC) Received: by mail-vk0-f65.google.com with SMTP id 23so7289516vkc.2 for ; Fri, 20 Jan 2017 17:10:41 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Matthew Wilcox Date: Fri, 20 Jan 2017 20:10:40 -0500 Message-ID: To: Andy Lutomirski Content-Type: multipart/alternative; boundary=001a114388cc5e17070546906ff1 Cc: Josh Armour , Greg Kroah-Hartman , 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: , --001a114388cc5e17070546906ff1 Content-Type: text/plain; charset=UTF-8 [I swear Gmail used to have a "reply inline" option in the app] Maybe we really want a "call this kernel function with user privilege" ability? Such a function would be able to access only user space memory (via get_user/...) and its own stack (all hail vmap). All the compat code would benefit, and maybe some upper layers of ioctl handling. Perhaps some of the filesystem parsing code would do well in this kind of constrained environment, but it might need access to so much other stuff we'd end up diluting the utility. On Jan 20, 2017 19:23, "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? A minor one for x86: give binaries a way to opt out of the x86_64 vsyscall page. I already did the hard part (in a branch), so all that's really left is figuring out the ABI. On Fri, Jan 20, 2017 at 2:38 PM, Kees Cook wrote: > Hi, > > I've already got various Kernel Self-Protection Project TODO items > collected[1] (of varying size and complexity), but recently Google's > Patch Reward Program[2] is trying to expand by helping create a bounty > program for security-related TODOs. KSPP is just one corner of > interest in the kernel, and I'd love to know if any other maintainers > have TODO items that they'd like to see get done (and Google would > potentially provide bounty money for). > > Let me know your security wish-lists, and I'll collect them all into a > single place. And if there is a better place than ksummit-discuss to > reach maintainers, I'm all ears. LKML tends to mostly just serve as a > public archive. :) > > Thanks! > > -Kees > > [1] http://kernsec.org/wiki/index.php/Kernel_Self_Protection_ Project#Specific_TODO_Items > [2] https://www.google.com/about/appsecurity/patch-rewards/ > > -- > Kees Cook > Nexus Security > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- Andy Lutomirski AMA Capital Management, LLC _______________________________________________ Ksummit-discuss mailing list Ksummit-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss --001a114388cc5e17070546906ff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[I swear Gmail used to have a "reply inline&quo= t; option in the app]

Ma= ybe we really want a "call this kernel function with user privilege&qu= ot; ability? Such a function would be able to access only user space memory= (via get_user/...) and its own stack (all hail vmap).

All the compat code would benefit, and maybe= some upper layers of ioctl handling. Perhaps some of the filesystem parsin= g code would do well in this kind of constrained environment, but it might = need access to so much other stuff we'd end up diluting the utility.

On = Jan 20, 2017 19:23, "Andy Lutomirski" <luto@amacapital.net> wrote:
=
This is not easy at all, but: how about rewriting = execve() so that the
actual binary format parsers run in user mode?

A minor one for x86: give binaries a way to opt out of the x86_64
vsyscall page.=C2=A0 I already did the hard part (in a branch), so all
that's really left is figuring out the ABI.

On Fri, Jan 20, 2017 at 2:38 PM, Kees Cook <keescook@chromium.org> wrote:
> Hi,
>
> I've already got various Kernel Self-Protection Project TODO items=
> collected[1] (of varying size and complexity), but recently Google'= ;s
> Patch Reward Program[2] is trying to expand by helping create a bounty=
> program for security-related TODOs. KSPP is just one corner of
> interest in the kernel, and I'd love to know if any other maintain= ers
> have TODO items that they'd like to see get done (and Google would=
> potentially provide bounty money for).
>
> Let me know your security wish-lists, and I'll collect them all in= to a
> single place. And if there is a better place than ksummit-discuss to > reach maintainers, I'm all ears. LKML tends to mostly just serve a= s a
> public archive. :)
>
> Thanks!
>
> -Kees
>
> [1] http://= kernsec.org/wiki/index.php/Kernel_Self_Protection_Project#Specifi= c_TODO_Items
> [2] https://www.google.com/about/ap= psecurity/patch-rewards/
>
> --
> Kees Cook
> Nexus Security
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-d= iscuss@lists.linuxfoundation.org
> https://lists.linuxfoundation= .org/mailman/listinfo/ksummit-discuss



--
Andy Lutomirski
AMA Capital Management, LLC
____________________________________= ___________
Ksummit-discuss mailing list
Ksummit-discus= s@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

--001a114388cc5e17070546906ff1--