Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6694761ybi; Wed, 29 May 2019 11:37:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqyTdgB/kjRx3yG/iXTMHYBeVI2yiS2I2VHDW6XLItNMwz5VS2Xw0LWjIo3et7AGfgDFDmXl X-Received: by 2002:a62:1692:: with SMTP id 140mr127616293pfw.166.1559155035470; Wed, 29 May 2019 11:37:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559155035; cv=none; d=google.com; s=arc-20160816; b=R+AQnzf6Trcvzid7B9pbUSzuz0f4OTHIW59Ktn7a+fmRaa2IYPnGJxbOq/ECzBpPRv Bfmvkr/fzVcU/lA8tEbjf+9mBeme/FE0LzPFSdaxJsZTu9xyOSKY9DaMP6e7dKT1Ei0o xeAhM337D28hIgQsyahyqos6qkG6+8RTZRqmM+dzzzuT8aDFr9gZ7QIraDErcVQVR3Ow 1uQ8cRTyO+Y6ngOgHB3G7UhYQ7wSH8EMy8mQAvvOCPBt4DHXyuyvvt4FXhhiMUujcL9T uzj2Tan+jm0Mx7jDneSEzU+OnX2vsJqJ2uDMLnJS4fyavlrGT3wcQQA6O066aflbFISk DgqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=v1brlopRODFYIOi3P9DZDOil1yY2RDrp+jg+VGWZC8A=; b=h+V+qTPxGfEz3zhY2sKf5vt/83fZzq1ZcjuIUbRPOg4mkif0wDrRD3xbZUuwVdoRMo OAPnoqr268rPTwkWzH43pN0SiRUb4ECdswWz2fLQq6XMZ8sDke0b5GvIVLcBjOZuRD2h lc2I/jymbg0j3PKssJ0eL6x0u4HvOmsOCFe/gDKIiK6vh/TYqBlnBEWXZGphh3sB1bcv QDsoDX6WqgRyKp6B95E98ya8RwjWyNlOw14kT4eHWHFSZEip3oMRGu1JAVzpGUXNO+iB Dkp4lgks6E3tfXCxqPcoERzUXTvm7+wHQ22uKHFSAftzgagyfpjy7NIK1jP4E9es9pYh 7CmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YyD6uuq6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q195si557762pgq.119.2019.05.29.11.36.58; Wed, 29 May 2019 11:37:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=YyD6uuq6; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727066AbfE2Sfs (ORCPT + 99 others); Wed, 29 May 2019 14:35:48 -0400 Received: from mail-pf1-f194.google.com ([209.85.210.194]:37179 "EHLO mail-pf1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbfE2Sfs (ORCPT ); Wed, 29 May 2019 14:35:48 -0400 Received: by mail-pf1-f194.google.com with SMTP id a23so2195571pff.4 for ; Wed, 29 May 2019 11:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=v1brlopRODFYIOi3P9DZDOil1yY2RDrp+jg+VGWZC8A=; b=YyD6uuq6pD5bXcJVpcO4CLkcCDDeuU9UhKxI+9lMQvf0FpBqWgQgdE/s3bdezUB8Ax Q5AztHb/Xh7JVv35VfmtkGp9NK96mN9JQWakRhySHq3dthHjxfXyCCSl+s5ZleF6e4Cx GxXk6HyUHF5aCEmHHePRd05mQwg0yfdg0wdwc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=v1brlopRODFYIOi3P9DZDOil1yY2RDrp+jg+VGWZC8A=; b=ZbkM553lz+VElRCo9+pIgj6nQCcKM1H7VHpSv6YEkHmneIyVNiqVxwpwA+tDLLp9fb UMUMCnmvc+QHqZaZ8miTIE3QPq2rNnnOxe16T1LTuXU/tZuR0vfUiveyCfH4d7whViFV 1aGgG7dA/5hOdm9J29skldLbg85o7Ng4qTdvsapvTF7Wp0Nn71Zl0rj1fxBoFGk1+G0Y weq/JC30tx1oaVdo7sbL/I8I9So6/etd9lbRzYISpFofV5HUfCATEovdWguPqo26IXWI wQ5qeSRp761uO4hRqIl7tuFEcCCeACRFvBYXIu3SOEFna/vDgUMuwVagUUItBjCmv8N3 CZNw== X-Gm-Message-State: APjAAAXyzzWhZlGG2ToCt1vycXKrmLxqDYzHYeTQ7LUUD2lIFet1ueAR 6L9I0dtaGfPEnW0tKj2GmT0IGA== X-Received: by 2002:a63:ed09:: with SMTP id d9mr24044102pgi.419.1559154947660; Wed, 29 May 2019 11:35:47 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id n2sm112146pgp.27.2019.05.29.11.35.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 May 2019 11:35:46 -0700 (PDT) Date: Wed, 29 May 2019 11:35:45 -0700 From: Kees Cook To: "Reshetova, Elena" Cc: Theodore Ts'o , 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: <201905291134.3D40F13@keescook> References: <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> <20190528133347.GD19149@mit.edu> <2236FBA76BA1254E88B949DDB74E612BA4CABA56@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4CABA56@IRSMSX102.ger.corp.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 29, 2019 at 10:13:43AM +0000, Reshetova, Elena wrote: > Not sure about ideal params for the whole combination here since security > and performance are basically conflicting with each other (as usual). > So, that's why I was trying to propose to have two version of this: > - one with tilt towards performance (rdtsc based) > - one with tilt towards security (CRNG-based) > And then let users choose what matters more for their workload. > For normal things like dektops, etc. CRNG based version won't provide > any noticeable overhead. It might only matter for syscall sensitive workloads, > which btw, most likely not enable quite a bunch of other security protections, I think people that care about this would prefer the CRNG, and will be much less interested in the performance issues. But giving people the option to choose it at runtime seems sensible. Though really, for any "real" workloads, it's totally lost in the noise, even with the CRNG. > so I would say that for them to have even rdtsc() version is actually an > improvement in their defenses for stack (and basically no impact on performance). Yeah, I think a static-key based version of this would be very nice and would stay out of anyone's way that didn't want it. -- Kees Cook