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 1fOUJ8-0003li-Qt for speck@linutronix.de; Thu, 31 May 2018 22:36:27 +0200 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AEFDA818BAFD for ; Thu, 31 May 2018 20:36:19 +0000 (UTC) Received: from treble (ovpn-120-231.rdu2.redhat.com [10.10.120.231]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 87A7D2024CA1 for ; Thu, 31 May 2018 20:36:19 +0000 (UTC) Date: Thu, 31 May 2018 15:36:18 -0500 From: Josh Poimboeuf Subject: [MODERATED] Re: spectrev1+ Message-ID: <20180531203618.ve47oad37oemb5l3@treble> References: <20180531144653.GJ12217@hirez.programming.kicks-ass.net> <20180531184949.fk43jyh6l3fitrcw@treble> 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 08:55:12PM +0200, speck for Jiri Kosina wrote: > On Thu, 31 May 2018, speck for Josh Poimboeuf wrote: > > > > 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? > > The is_read() check is there AFAIK for the user-controlled value > (user_index above), while this new variant requires storing the attacker > specified value, so such smatch rule wouldn't trigger. > > But this all should better be clarified by Dan ... My (probably wrong) understanding is that the pattern is something like this: if (user_index < array_len) { bar[user_index] = blah; ... foo = bar[user_index]; } Do you have a different understanding? -- Josh