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: <20190509084352.GA96236@gmail.com>
Date:   Thu, 9 May 2019 10:43:52 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     "Reshetova, Elena" <elena.reshetova@...el.com>
Cc:     David Laight <David.Laight@...LAB.COM>,
        Andy Lutomirski <luto@...nel.org>,
        Theodore Ts'o <tytso@....edu>,
        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>,
        "keescook@...omium.org" <keescook@...omium.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


* Reshetova, Elena <elena.reshetova@...el.com> wrote:

> > I find it ridiculous that even with 4K blocked get_random_bytes(), 
> > which gives us 32k bits, which with 5 bits should amortize the RNG 
> > call to something like "once per 6553 calls", we still see 17% 
> > overhead? It's either a measurement artifact, or something doesn't 
> > compute.
> 
> If you check what happens underneath of get_random_bytes(), there is a 
> fair amount of stuff that is going on, including reseeding CRNG if 
> reseeding interval has passed (see _extract_crng()). It also even 
> attempts to stir in more entropy from rdrand if avalaible:
> 
> I will look into this whole construction slowly now to investigate. I 
> did't optimize anything yet also (I take 8 bits at the time for 
> offset), but these small optimization won't make performance impact 
> from 17% --> 2%, so pointless for now, need a more radical shift.

So assuming that the 17% overhead primarily comes from get_random_bytes() 
(does it? I don't know), that's incredibly slow for something like the 
system call entry path, even if it's batched.

If so then maybe we have to find something else? RDRAND was just my 
desperate suggestion to find something faster, I assumed a modern chip 
would find no trouble finding plenty of source of quantum randomness, 
given how much it has to fight it just to keep working - but that 
assumption was apparently wrong. ;-)

Is there no cryptographically robust yet fast (pseudo-)random sequence 
generator that is unlikely to be cracked real-time?

The performance bar that such a feature has to cross should be very high, 
given how the whole threat model and justification is dubious to begin 
with.

Or just give up on the whole notion if it cannot be done? ;-)

Thanks,

	Ingo