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 227431382C5 for ; Thu, 4 Jan 2018 14:17:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 356D3E08DD; Thu, 4 Jan 2018 14:17:26 +0000 (UTC) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (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 BB4D1E08A2 for ; Thu, 4 Jan 2018 14:17:25 +0000 (UTC) Received: by mail-pl0-x243.google.com with SMTP id 62so1096609pld.7 for ; Thu, 04 Jan 2018 06:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=61SfNF1sN/kpheDNa+uGpEFQrr/C8rlTyt9LOp0VHsM=; b=H936COfgylmXm2Dq3s+AsJv1wdb5cKB++zyIRRKWbp2MNnkj0A4F/6AhkgB+pzdISa rCgN5EX2i87kZTNTKkKUARQZ/kCnFAazngY9aZhp5hlQLfd9X5rajbEoOt1iNvsN0/xx iSDan3gQmisBfDYwLRSjctO6aZU3HWC3UlXgGfn9wEX/jSj123U8dUqZwjPW8Xn7efLU e1A9Iw+fTylZyedw62Ab3kAkzgZihpE2uX9DlNzdFD7OsD0Gtcf9xr5RWZFmnCNL5Okd zkFVT79+XvytCkzfXGbunpR0XqpljUYM3pVfizBZVURG7SYzQYh+29+Rna9xiqY4SyKD e2OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=61SfNF1sN/kpheDNa+uGpEFQrr/C8rlTyt9LOp0VHsM=; b=MlBsaLnegGqH+ar/A/QaEnetHuUzHwFxZEdXI8nVv+evCWCGoyY7Ci7gQpszWK8bpa 2W5kufA0veZXZCALQoqYrYUW7d4ZBargPJ/yuQXflVJvEfWmcRdmCxN5nBZo79qwZiIT PXCtVHteqZN35YUsiuNRFjvTONw8OLl1Z1/ohiojD8FpO5Xu7zSzVrukrAtxpxdsMsk5 8DwQ9rbWW5NVHyjGwR6n/onNsSSVRnbIsdaVVjctuCR2ItfEP/kfzXBh/5j5l6mV6CRr /8hHapCCUE3xCxNLYL6vgSMBsP5AZT1jjJytgS/UNpPO7VQpX58qB0DONqmdvCH69HaR sRjw== X-Gm-Message-State: AKGB3mIwqNMz+GPDf4kWJ+4Xb5B4keGve1XuXyR8hfDKbCNc66PQ++sm W8t07aSr003a9SfpkzrTmpI5twehoo85ax71IObi+Kdp X-Google-Smtp-Source: ACJfBovMiHIhnPVXEYjFvHYBbGGWZUAusPebB/YvU4VEzAWmWHwQmjr/hMY1baRFAGO4CxeaMpcKwMUAECcSWTkKs0c= X-Received: by 10.124.22.145 with SMTP id v17mr4727579ply.230.1515075444090; Thu, 04 Jan 2018 06:17:24 -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 Sender: freemanrich@gmail.com Received: by 10.100.151.169 with HTTP; Thu, 4 Jan 2018 06:17:23 -0800 (PST) In-Reply-To: <92ab5d0f-6111-cdec-5443-4f0cb0712eaf@charter.net> References: <92ab5d0f-6111-cdec-5443-4f0cb0712eaf@charter.net> From: Rich Freeman Date: Thu, 4 Jan 2018 09:17:23 -0500 X-Google-Sender-Auth: Eq7tfOjWVx80uUGyE5iEC07TyUM 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: bfa815b7-6940-4659-8a4a-aaecdeb23b9d X-Archives-Hash: e2623b2f240e4f9ac19c2c16d24b276c On Thu, Jan 4, 2018 at 8:44 AM, Corbin Bird wrote: > > According to the Project Zero documentation .... having BPF JIT enabled > is the key to the exploit. > > The way the docs read ... can it be assumed that by having BPF JIT > disabled on an AMD, that blocks this exploit? > I'm still working through the details, but AMD seems to only be vulnerable to variant 1 (based on AMD's reports), and for Linux that requires that BPF JIT be both built into the kernel (compile-time), and enabled in sysctl (net.core.bpf_jit_enable). From what I can tell variant 1 requires that the vulnerable code actually be executed in the kernel security context. I'm sure a fix to BPF will be made to close that. There might also be some other code that can be tricked in the kernel but there are no reports of this. For variant 2 (not exploitable on AMD), it sounds like the BPF code need merely be present in kernel virtual memory while running in user security context. That would mean that it would need to be built at compile-time, and loaded (if in a module), but it wouldn't have to be enabled in sysctl. I didn't see any mention of it but I would think that the PTI fixes might close this hole on Intel, since then when the CPU is in user security context the BPF code would not be present in virtual memory. Intel posted a separate compile-time fix to lkml yesterday as well, with an amusing response from Linus in his usual style, and an even more amusing subsequent joke about needing to add a perl interpreter to the kernel. Variant 1 does exploit CPU behavior, but I suspect it could be fixed with a change to gcc to recognize these kinds of indirect memory references and ensure they're not executed speculatively. That fix would be applicable to anything that runs untrusted code in a sandbox, such as browsers. That variant isn't about crossing CPU privilege boundaries so much as getting code that is legitimately being run to leak state through the cache as a backchannel. Note: I'm not an expert on any of this stuff, and if somebody wants to chime in with details/adjustments to the above I'm all ears. -- Rich