From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6AA12C04AB6 for ; Tue, 28 May 2019 13:35:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4611A20883 for ; Tue, 28 May 2019 13:35:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727372AbfE1Nfi (ORCPT ); Tue, 28 May 2019 09:35:38 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:53752 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726924AbfE1Nfh (ORCPT ); Tue, 28 May 2019 09:35:37 -0400 Received: from callcc.thunk.org ([66.31.38.53]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4SDXlm5010515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 May 2019 09:33:48 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 794F7420481; Tue, 28 May 2019 09:33:47 -0400 (EDT) Date: Tue, 28 May 2019 09:33:47 -0400 From: "Theodore Ts'o" To: "Reshetova, Elena" Cc: Kees Cook , Ingo Molnar , Andy Lutomirski , David Laight , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , Peter Zijlstra , Daniel Borkmann , "linux-kernel@vger.kernel.org" , "jpoimboe@redhat.com" , "jannh@google.com" , "Perla, Enrico" , "mingo@redhat.com" , "bp@alien8.de" , "tglx@linutronix.de" , "gregkh@linuxfoundation.org" , "Edgecombe, Rick P" , Linus Torvalds , Peter Zijlstra Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall Message-ID: <20190528133347.GD19149@mit.edu> Mail-Followup-To: Theodore Ts'o , "Reshetova, Elena" , Kees Cook , Ingo Molnar , Andy Lutomirski , David Laight , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , Peter Zijlstra , Daniel Borkmann , "linux-kernel@vger.kernel.org" , "jpoimboe@redhat.com" , "jannh@google.com" , "Perla, Enrico" , "mingo@redhat.com" , "bp@alien8.de" , "tglx@linutronix.de" , "gregkh@linuxfoundation.org" , "Edgecombe, Rick P" , Linus Torvalds , Peter Zijlstra References: <20190508113239.GA33324@gmail.com> <2236FBA76BA1254E88B949DDB74E612BA4C762F7@IRSMSX102.ger.corp.intel.com> <20190509055915.GA58462@gmail.com> <2236FBA76BA1254E88B949DDB74E612BA4C7741F@IRSMSX102.ger.corp.intel.com> <20190509084352.GA96236@gmail.com> <201905111703.5998DF5F@keescook> <20190512080245.GA7827@gmail.com> <201905120705.4F27DF3244@keescook> <2236FBA76BA1254E88B949DDB74E612BA4CA8DBF@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4CA8DBF@IRSMSX102.ger.corp.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I confess I've kind of lost the plot on the performance requirements at this point. Instead of measuring and evaluating potential solutions, can we try to approach this from the opposite direction and ask what the requirements are? What's the maximum number of CPU cycles that we are allowed to burn such that we can meet the 1-2% overhead? And how many bits of uncertainty are we trying to present to the attacker? What's the minimum beyond we shouldn't bother? (Perhaps because rdtsc will give us that many bits?) And does that change if we vary the reseed window in terms of the number of system calls between reseeding? And what are the ideal parameters after which point we're just gilding the lily? - Ted