From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com ([156.151.31.85]) by Galois.linutronix.de with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fOnbh-0003yZ-Ob for speck@linutronix.de; Fri, 01 Jun 2018 19:12:54 +0200 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w51HBH0F188123 for ; Fri, 1 Jun 2018 17:12:46 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2janjedpqx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 01 Jun 2018 17:12:46 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w51HCjfX028271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 1 Jun 2018 17:12:45 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w51HCj0d026425 for ; Fri, 1 Jun 2018 17:12:45 GMT Date: Fri, 1 Jun 2018 13:12:44 -0400 From: Konrad Rzeszutek Wilk Subject: [MODERATED] Re: spectrev1+ Message-ID: <20180601171244.GA30216@char.us.oracle.com> References: 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 02:41:46PM -0400, speck for Jon Masters wrote: > On 05/31/2018 08:50 AM, speck for Jiri Kosina wrote: > > > so, according to the information I have, this is likely to go public on > > 2018-06-12 (it's the one referred to as "Bounds Check Bypass Store" in the > > documents). > > Correct. We've been asking Intel to extend this while tooling is > confirmed to be identifying all the potential sites, and are in > discussions with other vendors to coordinate that ask. > > > I've specifically asked Intel for permission to allow Dan Carpenter to be > > briefed on this issue, so that he could try to teach smatch about > > detecting such patterns (IIUC it should be in principle as simple as > > changing his spectrev1 check to also look for stores and not just reads) > > some time ago. > > Dan is covered under an agreement between Oracle and Intel and is > already aware of the issue. He's also been working on tooling. I defer > to Konrad on whether he can/should be on the list for other issues. Hi! Sorry for the late response. Went on vacation and email backlog. Dan has been informed about this disclosure, I will double check whether he got all or just this one. And also figuring out whether Dan's understanding of the disclosure and what his tool currently does - is exactly what the disclosure speaks off. > > > Has anyone here tried to teach any semantic analysis tool about this > > code pattern? > > We have a binary scanner tool but as Josh said, it's not yet quite > right. Btw, for the store variant, it's essentially acknowledging that a > store implies a load. I think the existing tools are probably > insufficient to catch all instances of this, which is why I've asked for > this deadline (which isn't dependent on a third party) to be extended. > > Jon. > > -- > Computer Architect | Sent from my Fedora powered laptop >