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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 30588C28CC0 for ; Wed, 29 May 2019 10:51:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1091E21019 for ; Wed, 29 May 2019 10:51:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726411AbfE2Kvr convert rfc822-to-8bit (ORCPT ); Wed, 29 May 2019 06:51:47 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:42073 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725894AbfE2Kvq (ORCPT ); Wed, 29 May 2019 06:51:46 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-193-tjoSKSwtOfSt0uX1-9NT_Q-1; Wed, 29 May 2019 11:51:42 +0100 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 May 2019 11:51:42 +0100 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Wed, 29 May 2019 11:51:42 +0100 From: David Laight To: "'Reshetova, Elena'" , Theodore Ts'o CC: Kees Cook , Ingo Molnar , "Andy Lutomirski" , 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 Thread-Topic: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall Thread-Index: AQHU81HQwzT9MH4dM0y/JZXnSwiYT6Y8wW2AgAAdM1CAAXexAIAANZ3ggAAW1gCAAApRgIAAMeKAgAAd+PCAAQuGgIAAYQuAgAAKhwCACsPi4IADJTwAgAAcagCAAExngIAEBbGAgACIbACAAbyQ8IAA626AgAGZfXCAAARpgIAAWpuAgAAF74CAABf/AIAAAvkAgAGZnrD///dzgIAHjbaA///31ICAAC4VAIABBxmAgAAfuaCAAA5FAIAED8OAgAAYaYCAAINWgIAAbRaAgBjvMfCAACWEgIABZK1ggAAKveA= Date: Wed, 29 May 2019 10:51:41 +0000 Message-ID: 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> <20190528133347.GD19149@mit.edu> <2236FBA76BA1254E88B949DDB74E612BA4CABA56@IRSMSX102.ger.corp.intel.com> In-Reply-To: <2236FBA76BA1254E88B949DDB74E612BA4CABA56@IRSMSX102.ger.corp.intel.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: tjoSKSwtOfSt0uX1-9NT_Q-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Reshetova, Elena > Sent: 29 May 2019 11:14 .... > On related note: the current prng we have in kernel (prandom) is based on a > *very old* style of prngs, which is basically 4 linear LFSRs xored together. I'm no expert here (apart from some knowledge of LFRS/CRC) but even adding the results of the 4 LFSR (instead of xor) will make the generator much more secure (aka computationally expensive to reverse) without affecting the randomness or repeat cycle. FWIW if you are going to merge LFRS you probably want to clock them different numbers of times (+ve or -ve) otherwise the output 'mostly' shifts one bit per clock and the same bits tend to get merged. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)