From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 74BD11382C5 for ; Fri, 5 Jan 2018 02:22:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4F756E0BAF; Fri, 5 Jan 2018 02:22:21 +0000 (UTC) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DD28DE0B94 for ; Fri, 5 Jan 2018 02:22:20 +0000 (UTC) Received: by mail-yb0-x236.google.com with SMTP id f201so1380330ybg.6 for ; Thu, 04 Jan 2018 18:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=6wQ1yDFNuKwFkwyD5JkRDC4znTva1rFsbFb8+47X58c=; b=kvmUYWtpKDE0ftF2SqlvaUKNUj14l5bbvCTRtuWIz7x5T6rsZ2caWhj64g25x9S4LS iJvjkqfH2+kD04Hoy4H5+JiBt5FWGxpXhetcUd49lRwe+XI7OK1+DD2TXJ6o/h+ojQ9o 9ItDkK9GtTOU8b59NOYb98Ez+Jl185dV6be46h8GTtslBRZ5BMugcMNSKMZjOS2Lhh2Y Mf5Szc13iy+yU+IJAx2k3qT2tyfxfuKY4ww8y11cRfDI6lPQvmP3R8eIalzYEAMZYq2h /KxJfiuTzqffOncQPWmWfKRXABifOzIEnoNdEXkvFkDsj8xqIP2bQH/dEDKll1dIEQoN LEog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=6wQ1yDFNuKwFkwyD5JkRDC4znTva1rFsbFb8+47X58c=; b=borqDBiWfEWgoA/Seg6bYzjH8fAKB3QTZFDfwwcQTOn/or9iAwyU8VQXNDHchXradf WewfrJ2rk00s8Hz3DRgkVhJa71gTiHM8hQwM2xquDd3MW+U6eEdu87MK/JoyuxX7A2xg /OIPZ3a8rdxlgCglwPK7xLnQ14Ah18C6RRltNZfDNnr1UxQ8phT3vx6z14162WJRq3zx DXcC5m4ebYzWBUPjEt08b9SzRBiNIJuUwuzbToeNBLOI0qzm9zwHKVM92IlfkCiLgE8E ntqVpxtYfKlwBDVyCHs3JhDV7cLafI4lTljIBLy2A2hufzF0jmgZvRv7+3m/Q4y82Q06 NNXw== X-Gm-Message-State: AKGB3mKeDC5o9WQOc7cg31j4lhyWAogt73IuDCxUE5cgVQXDJ48jGoUR hekBOvYfZmy/vNXZcOSaTKrWfX1V5ZUC+FMsyGPtwA== X-Google-Smtp-Source: ACJfBotOCxt1RUcqlii003IzS3fuH1t3GjvhOR19ip6NwNOBHIpcxN8jokYgOQ7LCXBOKc5CU5cyau8EySbPwXxhHjE= X-Received: by 10.37.95.76 with SMTP id h12mr634867ybm.90.1515118939460; Thu, 04 Jan 2018 18:22:19 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.129.157.2 with HTTP; Thu, 4 Jan 2018 18:22:18 -0800 (PST) In-Reply-To: References: <92ab5d0f-6111-cdec-5443-4f0cb0712eaf@charter.net> From: R0b0t1 Date: Thu, 4 Jan 2018 20:22:18 -0600 Message-ID: Subject: Re: [gentoo-user] Expect a ~15% average slowdown if you use an Intel processor To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: efe04ae9-0c69-4fa0-b6b5-38092eb2d88f X-Archives-Hash: cace5b4ff2aafc87f439fca4d9f3151c On Thu, Jan 4, 2018 at 10:18 AM, Rich Freeman wrote: > On Thu, Jan 4, 2018 at 10:44 AM, R0b0t1 wrote: >> >> I am still working through the information myself, but it looks like >> BPF filters are an easy way to make sure you have something to look >> for in kernelspace. > > My understanding is that for exploit 1 to work you need to have the > kernel execute some code for you, and BPF is a way to do that because > it is a JIT compiler. > > The bits about finding where BPF is in kernelspace is for exploit 2, > which requires branching into that code, which requires knowing its > address. > What I think is missing is the full details of the cache behavior, because I saw some (ad hoc) proposals that the situation may be very, very bad indeed. I'll see if I can find the explanation involving only usermode code. The original recommendation from CERT was to fully replace all hardware: https://webcache.googleusercontent.com/search?q=cache:rzc6iQmgrIcJ:https://www.kb.cert.org/vuls/id/584653+&cd=4&hl=en&ct=clnk&gl=us >> On Thu, Jan 4, 2018 at 9:44 AM, R0b0t1 wrote: >>> But, if they do, >> >> then AMD processors are susceptible in the same way, and the issue can >> not be fixed. There are some news pieces and commenters claiming that >> AMD processors suffer similar issues. > > AMD published this: > https://www.amd.com/en/corporate/speculative-execution > > This tends to go along with Google's statement that AMD is vulnerable > to variant 1, but not 2 or 3. > > There is plenty of speculation going on with the hazy info that was > provided, but none of the original sources suggest that AMD is > vulnerable to variant 3. For variants 1/2 Google says that AMD is > susceptible to only 1, and the white paper says that they're > vulnerable to either 1/2 but they don't say which specifically. > > In any case, short of somebody publishing actual exploit code so that > people can run their own tests, I'm going to go with AMD. Nobody > reputable is outright contradicting their statements. For variant 1 > the only known vulnerability is BPF which probably next to nobody > uses, and for variant 2 there really aren't any alternatives available > right now anyway. > I think referring to BPF is a red herring, because it is really the processor that is at fault. Not BPF. And yes, I'm aware of what AMD claims. Cheers, R0b0t1