From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx3-rdu2.redhat.com ([66.187.233.73] helo=mx1.redhat.com) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fOSe5-0002oe-FP for speck@linutronix.de; Thu, 31 May 2018 20:49:57 +0200 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9130DBB43C for ; Thu, 31 May 2018 18:49:51 +0000 (UTC) Received: from treble (ovpn-120-231.rdu2.redhat.com [10.10.120.231]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 696751DB25 for ; Thu, 31 May 2018 18:49:51 +0000 (UTC) Date: Thu, 31 May 2018 13:49:49 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: spectrev1+ Message-ID: <20180531184949.fk43jyh6l3fitrcw@treble> References: <20180531144653.GJ12217@hirez.programming.kicks-ass.net> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Thu, May 31, 2018 at 04:55:53PM +0200, speck for Jiri Kosina wrote: > On Thu, 31 May 2018, speck for Peter Zijlstra wrote: > > > I'll try and reach out to Dan too; but I think the current smatch > > pattern is sufficient. > > > > IIRC smatch currently looks for any user controlled array index and > > doesn't care what, if anything, happens afterwards. This matches with > > the kernel policy of killing the speculation dead ASAP and not bothering > > to see if the (or any) gadget completes. > > > > The fact that this variant uses a slightly different ending (but still > > uses the cache side-channel) should be immaterial. IIRC one of the sites > > detected by smatch didn't have a cache side-channel but it did have an > > almost perfect branchscope side-channel ending. > > Thanks; so my understanding was that Dan's current smatch rule contains > 'is_read()' check somewhere inside it, and therefore would basically warn > currently only about patterns a-la > > foo = bar[user_index]; > > Dropping that 'is_read()' seemed like what will be needed to identify > these new patterns, and he said he'll investigate it, but then I never > heard back. > > So if you can ping him from a different direction, that'd be helpful. Why would you drop the is_read()? The gadget involves both a write and a read, so the is_read() wouldn't exclude the pattern, would it? -- Josh