From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.eu.citrix.com ([185.25.65.24]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fR0tA-0003MB-Sk for speck@linutronix.de; Thu, 07 Jun 2018 21:48:05 +0200 Subject: [MODERATED] Re: spectrev1+ References: <20180601171244.GA30216@char.us.oracle.com> <20180601212952.GA7354@char.us.oracle.com> <20180604153815.GU12198@hirez.programming.kicks-ass.net> <20180605175837.ry5tx3widl6hj5ob@treble> From: Andrew Cooper Message-ID: <87b71a1e-df5a-abd0-e55d-66c63b045bab@citrix.com> Date: Thu, 7 Jun 2018 19:02:59 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Language: en-GB To: speck@linutronix.de List-ID: On 07/06/18 19:00, speck for Jiri Kosina wrote: > On Wed, 6 Jun 2018, speck for Jiri Kosina wrote: > >>> Can some Intel person explain how the processor could possibly >>> speculatively do a 'ret' instruction that actually uses the value that >>> the front-end doesn't even have (ie "not RSB/BTB")? >> I earlier today already asked for more details about exactly this back >> through the official channel I've received the whitepaper from as well. >> I'll relay any information I eventually receive to this list. > So apparently due to multiple questions Intel received about this, there > is going to be a more detailed version of the whitepaper with a more > detailed walk-through of the stack/ret based attack and we should stay > tuned ... that's unfortunately all the information I've received by now :/ > > Feels like they're still confident that the attack is somehow possible. Yeah - I got the same impression from a reply to my feedback on this subject. ~Andrew