From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Date: Tue, 21 Jun 2016 10:16:46 -0700 Message-ID: References: Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Sender: linus971@gmail.com In-Reply-To: To: Andy Lutomirski Cc: Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Borislav Petkov , Nadav Amit , Kees Cook , Brian Gerst , "kernel-hardening@lists.openwall.com" , Josh Poimboeuf , Jann Horn , Heiko Carstens List-Id: linux-arch.vger.kernel.org On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: > > So I'm leaning toward fewer cache entries per cpu, maybe just one. > I'm all for making it a bit faster, but I think we should weigh that > against increasing memory usage too much and thus scaring away the > embedded folks. I don't think the embedded folks will be scared by a per-cpu cache, if it's just one or two entries. And I really do think that even just one or two entries will indeed catch a lot of the cases. And yes, fork+execve() is too damn expensive in page table build-up and tear-down. I'm not sure why bash doesn't do vfork+exec for when it has to wait for the process anyway, but it doesn't seem to do that. Linus From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f195.google.com ([209.85.214.195]:34704 "EHLO mail-ob0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751983AbcFURXu (ORCPT ); Tue, 21 Jun 2016 13:23:50 -0400 Received: by mail-ob0-f195.google.com with SMTP id s7so3945934obo.1 for ; Tue, 21 Jun 2016 10:23:44 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Linus Torvalds Date: Tue, 21 Jun 2016 10:16:46 -0700 Message-ID: Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) Content-Type: text/plain; charset=UTF-8 Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Andy Lutomirski , the arch/x86 maintainers , Linux Kernel Mailing List , "linux-arch@vger.kernel.org" , Borislav Petkov , Nadav Amit , Kees Cook , Brian Gerst , "kernel-hardening@lists.openwall.com" , Josh Poimboeuf , Jann Horn , Heiko Carstens Message-ID: <20160621171646.EUwgJCo70qXEPNRtp9xq3ogejlUuuj_Ir5YqZfDf06M@z> On Tue, Jun 21, 2016 at 9:45 AM, Andy Lutomirski wrote: > > So I'm leaning toward fewer cache entries per cpu, maybe just one. > I'm all for making it a bit faster, but I think we should weigh that > against increasing memory usage too much and thus scaring away the > embedded folks. I don't think the embedded folks will be scared by a per-cpu cache, if it's just one or two entries. And I really do think that even just one or two entries will indeed catch a lot of the cases. And yes, fork+execve() is too damn expensive in page table build-up and tear-down. I'm not sure why bash doesn't do vfork+exec for when it has to wait for the process anyway, but it doesn't seem to do that. Linus