From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fOOzo-00075m-3t for speck@linutronix.de; Thu, 31 May 2018 16:56:11 +0200 Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id AE66BABCC for ; Thu, 31 May 2018 14:56:00 +0000 (UTC) Date: Thu, 31 May 2018 16:55:53 +0200 (CEST) From: Jiri Kosina Subject: [MODERATED] Re: spectrev1+ In-Reply-To: <20180531144653.GJ12217@hirez.programming.kicks-ass.net> Message-ID: References: <20180531144653.GJ12217@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: 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. Thanks, -- Jiri Kosina SUSE Labs