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: <20190528133347.GD19149@mit.edu>
Date:   Tue, 28 May 2019 09:33:47 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     "Reshetova, Elena" <elena.reshetova@...el.com>
Cc:     Kees Cook <keescook@...omium.org>, Ingo Molnar <mingo@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        David Laight <David.Laight@...lab.com>,
        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

I confess I've kind of lost the plot on the performance requirements
at this point.  Instead of measuring and evaluating potential
solutions, can we try to approach this from the opposite direction and
ask what the requirements are?

What's the maximum number of CPU cycles that we are allowed to burn
such that we can meet the 1-2% overhead?

And how many bits of uncertainty are we trying to present to the
attacker?  What's the minimum beyond we shouldn't bother?  (Perhaps
because rdtsc will give us that many bits?)  And does that change if
we vary the reseed window in terms of the number of system calls
between reseeding?

And what are the ideal parameters after which point we're just gilding
the lily?

					- Ted