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: <56e694bfbe2993389a9662b1477b74eaaca3c171.camel@intel.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ