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:   Wed, 24 Apr 2019 11:42:44 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     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>
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. 
In that case, we are only left with rdtsc-based variants. 
I guess for measuring I will have to use existing chacha20 kernel implementation, never used it before, so will check how to
use it/initialize, etc. 

Any other option I missed?

Best Regards,
Elena.