linux-kernel - RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c0345478194240aea930550ccc93353b@AcuMS.aculab.com>
Date:   Wed, 29 May 2019 10:51:41 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'Reshetova, Elena'" <elena.reshetova@...el.com>,
        Theodore Ts'o <tytso@....edu>
CC:     Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...nel.org>,
        "Andy Lutomirski" <luto@...nel.org>,
        Eric Biggers <ebiggers3@...il.com>,
        "ebiggers@...gle.com" <ebiggers@...gle.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        Peter Zijlstra <peterz@...radead.org>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "Perla, Enrico" <enrico.perla@...el.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

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)