From owner-freebsd-security@freebsd.org Thu Jan 4 18:24:50 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E0BEEABE06 for ; Thu, 4 Jan 2018 18:24:50 +0000 (UTC) (envelope-from mail@kkoenig.net) Received: from mx1.outerhaven.de (mx1.outerhaven.de [81.14.236.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21CE277B08 for ; Thu, 4 Jan 2018 18:24:49 +0000 (UTC) (envelope-from mail@kkoenig.net) Received: from [192.168.2.245] (big-shell.lan [192.168.2.245]) by mx1.outerhaven.de (OpenSMTPD) with ESMTPSA id 29b18422 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Thu, 4 Jan 2018 19:18:06 +0100 (CET) Subject: Re: clang way to patch for Spectre? To: freebsd-security@freebsd.org References: <291645341.20180104190237@serebryakov.spb.ru> <43417734-d420-5be9-333b-8d0d02d7a58a@freebsd.org> From: =?UTF-8?Q?Karsten_K=c3=b6nig?= Message-ID: Date: Thu, 4 Jan 2018 19:18:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <43417734-d420-5be9-333b-8d0d02d7a58a@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:24:50 -0000 Hi, On 01/04/2018 18:49, Julian Elischer wrote: > On 5/1/18 12:02 am, Lev Serebryakov wrote: >> Hello Freebsd-security, >> >> https://reviews.llvm.org/D41723 >> >> > not really.. > > What's to stop an unprivileged used bringing his own compiler? or a > precompiled binary? > >From my understanding: The patch is only for variant 2 of the Google P0 blog post[0]. Variant 2 describes how to access memory of a VM host from a guest by tricking kernel modules into caching arbitary inside the CPU cache. But if these are compiled with the patch[1] an attacker can't trick the kernel modules or other applications compiled with it. Best, Karsten [0] https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html [1] Which I assume to be correct, I haven't looked into it