Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 17 Apr 2019 08:24:54 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Theodore Ts'o <tytso@mit.edu>,
        David Laight <David.Laight@ACULAB.COM>,
        'Peter Zijlstra' <peterz@infradead.org>,
        "Reshetova, Elena" <elena.reshetova@intel.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        "luto@kernel.org" <luto@kernel.org>,
        "luto@amacapital.net" <luto@amacapital.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "jpoimboe@redhat.com" <jpoimboe@redhat.com>,
        "keescook@chromium.org" <keescook@chromium.org>,
        "jannh@google.com" <jannh@google.com>,
        "Perla, Enrico" <enrico.perla@intel.com>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] x86/entry/64: randomize kernel stack offset upon syscall
Message-ID: <20190417062454.GA45199@gmail.com>
References: <20190415060918.3766-1-elena.reshetova@intel.com>
 <20190415072535.GA51449@gmail.com>
 <2236FBA76BA1254E88B949DDB74E612BA4C4F90F@IRSMSX102.ger.corp.intel.com>
 <20190416073444.GC127769@gmail.com>
 <2236FBA76BA1254E88B949DDB74E612BA4C51962@IRSMSX102.ger.corp.intel.com>
 <20190416120822.GV11158@hirez.programming.kicks-ass.net>
 <01914abbfc1a4053897d8d87a63e3411@AcuMS.aculab.com>
 <20190416154348.GB3004@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190416154348.GB3004@mit.edu>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


* Theodore Ts'o <tytso@mit.edu> wrote:

> It seems though the assumption that we're assuming the attacker has 
> arbitrary ability to get the low bits of the stack, so *if* that's 
> true, then eventually, you'd be able to get enough samples that you 
> could reverse engineer the prandom state.  This could take long enough 
> that the process will have gotten rescheduled to another CPU, and since 
> the prandom state is per-cpu, that adds another wrinkle.

Yeah.

Note that if the attacker has this level of local access then they can 
probably also bind the task to a CPU, which would increase the 
statistical stability of any attack. Plus with millions of system calls 
per second executed in an attack, each of which system call exposes a 
couple of bits of prandom state, I'm pretty sure some prandom attack 
exists that can make the extraction of the full internal state probable 
within the ~60 seconds reseeding interval. (Is there any research on this 
perhaps, or do researchers not even bother, because this isn't really a 
secure algorithm in any reasonable meaning of the word?)

Thanks,

	Ingo