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 17:37:34 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "ebiggers@...gle.com" <ebiggers@...gle.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        "ebiggers3@...il.com" <ebiggers3@...il.com>,
        "David.Laight@...LAB.COM" <David.Laight@...LAB.COM>,
        "tytso@....edu" <tytso@....edu>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "luto@...nel.org" <luto@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "luto@...capital.net" <luto@...capital.net>,
        "Perla, Enrico" <enrico.perla@...el.com>
Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall

On Fri, 2019-04-26 at 12:33 +0100, Reshetova, Elena wrote:
> 1) rdtsc or variations based on it (David proposed some CRC-based variants for
> > example)
Hi,

Could we repeatedly measure the time for a short syscall on a quiet system and
estimate the entropy we get from this? In some scenarios the attacker might have
less control of the timing as well.

Since this is a statistical defense, assuming the argument can be made that
there is at least some randomness in the timer, and could at least be out of the
control of an attacker sometimes, I wonder if this feature could be valuable
before the search for a faster stronger random number generator completes.

Could that be a way forward for now?

Thanks,

Rick