Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp681804yba; Fri, 26 Apr 2019 07:06:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqz+blIV85dhQe9gDF6ffDAskgn+uP0HYuXbXHglFgcsz1nEPf+dKpJxsK2g9kYIA6v0FVT/ X-Received: by 2002:a65:6392:: with SMTP id h18mr43243667pgv.273.1556287571120; Fri, 26 Apr 2019 07:06:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556287571; cv=none; d=google.com; s=arc-20160816; b=Fw9R1jnKhVWD2/ZUUonqHD5M1k9M7ToyWb5J8Ed3BlMKAyd4DyQa4LPFWm0Trz7xrr iJ5ZS9GbVaIOJEXrpSyu7lDmZDFkq829+h+N4sCXsqB6cnzrp890Vbnf3DHfYRHHSund TM9HupB9GtQcuYz9DtB8NT11XSalxKLqHgS+93chfu38AZVYn37L9uJgKfeFcKO5foPO DL1n8iMFDK630H46dO4wdmzPe+mXsilT0/lQIiC4CibwYd9Jhuc0dfACtw9XCi0nQdeq rUd7iYyurq4bxUWdLtNxyUWxUGYA9QJ+cwVRMYDkKoKQihkI2h9CaEdhhEHkLmHZPHQ7 YN4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=1dpYlNwdYZOzYsjqp0u6r31TOGyLqI47R9wN9dg48W8=; b=WML5S4ZK+LZyE5YcsfzyMOynnYWdsSjMCtfeS3VU91UlQSUBT2mMF4ASoWwujZ6VOj Bgluyc3BFRj17aA1ig0vmFubEN05dwviZwIvsa2WabkTgMoS3Aors8h0OEsV5sWldZl2 +mnNUul7KOB2AVyCquj0QAw70FenlCXLIxxbpIq3TFPDoD3PPQoZX6Q+YnYuS9x2K3Y9 KjpZraH9FLyo4XAgm4EfXdQaVoGzBm4UbJL84itMsK8fKJB9I1mF1YyRGld1Ik1Rdkfw 2bzLopGcI+EGGo5Pr6zR4sYQdU0bs1/o0X681f9prYD2NTtGb+iJpEsnhv3QuuAlLuL5 41dQ== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 16si11893547pgl.194.2019.04.26.07.05.53; Fri, 26 Apr 2019 07:06:11 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726349AbfDZOCi (ORCPT + 99 others); Fri, 26 Apr 2019 10:02:38 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:54948 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726039AbfDZOCi (ORCPT ); Fri, 26 Apr 2019 10:02:38 -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 x3QE12pF023693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Apr 2019 10:01:03 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 240BF420EEC; Fri, 26 Apr 2019 10:01:02 -0400 (EDT) Date: Fri, 26 Apr 2019 10:01:02 -0400 From: "Theodore Ts'o" To: "Reshetova, Elena" Cc: Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , David Laight , Ingo Molnar , "'Peter Zijlstra'" , "keescook@chromium.org" , Daniel Borkmann , "luto@kernel.org" , "luto@amacapital.net" , "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" Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall Message-ID: <20190426140102.GA4922@mit.edu> Mail-Followup-To: Theodore Ts'o , "Reshetova, Elena" , Eric Biggers , "ebiggers@google.com" , "herbert@gondor.apana.org.au" , David Laight , Ingo Molnar , 'Peter Zijlstra' , "keescook@chromium.org" , Daniel Borkmann , "luto@kernel.org" , "luto@amacapital.net" , "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" References: <2236FBA76BA1254E88B949DDB74E612BA4C51962@IRSMSX102.ger.corp.intel.com> <20190416120822.GV11158@hirez.programming.kicks-ass.net> <01914abbfc1a4053897d8d87a63e3411@AcuMS.aculab.com> <20190416154348.GB3004@mit.edu> <2236FBA76BA1254E88B949DDB74E612BA4C52338@IRSMSX102.ger.corp.intel.com> <9cf586757eb44f2c8f167abf078da921@AcuMS.aculab.com> <20190417151555.GG4686@mit.edu> <99e045427125403ba2b90c2707d74e02@AcuMS.aculab.com> <2236FBA76BA1254E88B949DDB74E612BA4C5E473@IRSMSX102.ger.corp.intel.com> <2236FBA76BA1254E88B949DDB74E612BA4C63E24@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4C63E24@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 On Fri, Apr 26, 2019 at 11:33:09AM +0000, Reshetova, Elena wrote: > Adding Eric and Herbert to continue discussion for the chacha part. > So, as a short summary I am trying to find out a fast (fast enough to be used per syscall > invocation) source of random bits with good enough security properties. > I started to look into chacha kernel implementation and while it seems that it is designed to > work with any number of rounds, it does not expose less than 12 rounds primitive. > I guess this is done for security sake, since 12 is probably the lowest bound we want people > to use for the purpose of encryption/decryption, but if we are to build an efficient RNG, > chacha8 probably is a good tradeoff between security and speed. > > What are people's opinions/perceptions on this? Has it been considered before to create a > kernel RNG based on chacha? Well, sure. The get_random_bytes() kernel interface and the getrandom(2) system call uses a CRNG based on chacha20. See extract_crng() and crng_reseed() in drivers/char/random.c. It *is* possible to use an arbitrary number of rounds if you use the low level interface exposed as chacha_block(), which is an EXPORT_SYMBOL interface so even modules can use it. "Does not expose less than 12 rounds" applies only if you are using the high-level crypto interface. We have used cut down crypto algorithms for performance critical applications before; at one point, we were using a cut down MD4(!) for initial TCP sequence number generation. But that was getting rekeyed every five minutes, and the goal was to make it just hard enough that there were other easier ways of DOS attacking a server. I'm not a cryptographer, so I'd really us to hear from multiple experts about the security level of, say, ChaCha8 so we understand exactly kind of security we'd offering. And I'd want that interface to be named so that it's clear it's only intended for a very specific use case, since it will be tempting for other kernel developers to use it in other contexts, with undue consideration. - Ted