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]

Date:   Fri, 26 Apr 2019 11:33:09 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Eric Biggers <ebiggers3@...il.com>,
        "ebiggers@...gle.com" <ebiggers@...gle.com>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        David Laight <David.Laight@...LAB.COM>,
        'Theodore Ts'o' <tytso@....edu>,
        Ingo Molnar <mingo@...nel.org>,
        "'Peter Zijlstra'" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>
CC:     Daniel Borkmann <daniel@...earbox.net>,
        "luto@...nel.org" <luto@...nel.org>,
        "luto@...capital.net" <luto@...capital.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>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Subject: RE: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

> Hi,
> 
> Sorry for the delay - Easter holidays + I was trying to arrange my brain around
> proposed options.
> Here what I think our options are with regards to the source of randomness:
> 
> 1) rdtsc or variations based on it (David proposed some CRC-based variants for
> example)
> 2) prandom-based options
> 3) some proper crypto (chacha8 for example seems to be the lightest out of existing
> options,
> and probably enough for our purpose, but looks like kernel has only chacha20)
> 4) rdrand or other HW-based crypto
> 
> Option 4 was measured to be heavy for the purpose:
>    base:                     Simple syscall: 0.1774 microseconds
>    random_offset (rdtsc):     Simple syscall: 0.1803 microseconds
>    random_offset (rdrand): Simple syscall: 0.3702 microseconds
> 
> 
> Option 2 (even if we fork our own state(s), do it per-cpu, reseed, etc.) starts to look
> for me as the least desired.
> The existing generator's state, as people mentioned before, is trivially solvable given
> a very little amount of
> equations (syscalls in our case) you need to issue and offsets to leak.
> Even if we isolate the state/seed to just this purpose of stack randomization (and
> don't leak anything about the rest
> of the system or net prandom usage), it still probably makes the
> randomization more easily solvable than some constructs based on lower bits of
> rdtsc.
> In addition  building on top of existing kernel LFSR would add more (probably not
> useful for any other purpose)
> code, a possible misconception that it can be used for "real security", etc. So, I
> would propose to abandon this idea.
> 
> Option 3 we have to measure I guess, but if it is as heavy as rdrand, then this is also
> out.

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? 

Best Regards,
Elena.