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 82912138332 for ; Thu, 5 Apr 2018 22:40:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 20BD3E0976; Thu, 5 Apr 2018 20:13:02 +0000 (UTC) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::241]) (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 8E61AE0970 for ; Thu, 5 Apr 2018 20:13:01 +0000 (UTC) Received: by mail-pl0-x241.google.com with SMTP id 61-v6so18803269plb.2 for ; Thu, 05 Apr 2018 13:13:01 -0700 (PDT) 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=9BNQV80k79xflC0WZDCki0IX9jnnpYE+DRqQlphw7NY=; b=WLeMejeTz8uiU8CWcMTLhAqzdbUjwtavZBb0aeW9E4+9tjlmOhaRSfvHfMrV1yzGep tEJ9QAvYpJHuYPR3S8XHOSNRJ2tHR97Fir7X8oyRUvZ8qUueKLKjNFbuMB1MK6Vt013B M015yeHOVxHFMf7WXrxDgaxeLA17YdV0kHVcdVyS6lLlQWasetvgRruQWMUcYx3d3DkM JPcil8cHLBtFHq5LF7Sbzw+N8LqeCDZcqAnAl6NfgA3vvdVyllOwT3c/Nkx3dlRHqmYk jOuTexODHAtERB//hjzYshJoi+YBJeXMXRR1/YBFvIO5FvMFXd8fqYctbAWl4fgO/aLa HehQ== 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=9BNQV80k79xflC0WZDCki0IX9jnnpYE+DRqQlphw7NY=; b=HO+W5CpkcFw2F5EdTNEKvby3uS2yc5RfkElK9aeVQD6vX4kqtRpdNGiK9Ql2HZgfTm rD0n1Hm/tQs3jKV0QlvT3CeSqVCfPFs3EWxA4MHjKH8mTeefGnzdTZKzlFhHDfA5hNG4 NBckVjR5IMnGr0JTMc11d69/ZstxLk2z9/w3A0tOPKFtNUh64g9RAXJrVD4nmFwEajf8 k+nUVLcxk13+MEZ/zzdO2KPWav1qEsVGg0OFIMMh+sQunSm+gCag8J3wl6Z5oUOTocao io8TD2magl8FEoBO/7je+G2LgIfyb+DmSn0K1AJ+gYftYNo/Y26kOlM0wM7R4/bTBpRz N5Jw== X-Gm-Message-State: AElRT7FtKq7SFTv9mlPSYEyGz6GW77WR85sth1Oi4wIbj/WofrRATPn0 XCQFDrwHCgL7jfQk3nigWncQX4nD1qoVeDHG4cpkkg== X-Google-Smtp-Source: AIpwx4+vIiq8tcftg55/XYpOFgvFtw3P2qPq0cDnEDsHa4xEGv2mk54zH+CJcn8q0n28H/De3H/Hjn6bGazqd3bCDpw= X-Received: by 10.98.155.137 with SMTP id e9mr18282832pfk.109.1522959179779; Thu, 05 Apr 2018 13:12:59 -0700 (PDT) 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.236.174.22 with HTTP; Thu, 5 Apr 2018 13:12:59 -0700 (PDT) In-Reply-To: <5AC67AC1.1000007@youngman.org.uk> References: <8105793.sl6g6gt1vY@dell_xps> <5AC67AC1.1000007@youngman.org.uk> From: Rich Freeman Date: Thu, 5 Apr 2018 16:12:59 -0400 X-Google-Sender-Auth: QLihO-y6sWn48Bw3hD_5PDX0xZc Message-ID: Subject: Re: [gentoo-user] List of Intel CPUs that wont get Meltdown/Spectre fixes To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: cd929dc2-5b5c-45e1-8e6c-23efcdb481db X-Archives-Hash: afbbdb532d92ce8348deaa97ef1918e9 On Thu, Apr 5, 2018 at 3:36 PM, Wols Lists wrote: > On 05/04/18 17:54, Rich Freeman wrote: >> I >> haven't checked recently but the last time I looked at it even my >> current Ryzen CPU doesn't have a microcode fix out yet for lfence. > > Is lfence a meltdown problem? Because afaik Ryzen doesn't need a fix for > meltdown, it's not vulnerable. No, lfence is exclusively a fix for spectre. It has nothing to do with meltdown [1]. lfence itself has been around for a while, and works fine for its original purpose. It was intended to serialize reads from memory, so that any previous read operations were guaranteed to be complete before the lfence retires and execution moves on. However, lfence as it was originally defined does NOT prevent the CPU from fetching subsequent data into the cache, or to speculatively execute (but not retire) instructions. That is enough to allow for a spectre vulnerability. I believe the intent of these microcode changes is to basically overload some additional functionality on top of lfence that prevents some forms of speculative execution from continuing past it. However, I haven't really read much about the changes since the original publicity. At that time one concern I had was that it seemed like Intel and AMD were independently solving the problem, creating the potential that a code fix might work on one vendor's CPUs and not the other's. 1 - As a footnote, it makes sense that lfence couldn't do anything for Meltdown. Spectre is like most vulnerabilities in that it is a problem that must be present in the code that is being attacked. Meltdown is more of a hardware problem - you don't need any vulnerable code on a system to attack it. Now, meltdown does have a workaround that can be done at the kernel/hypervisor level. You can't fix meltdown simply by sticking instructions in the kernel's code path because when meltdown is exploited there isn't any kernel code running. With spectre the program being attacked IS the program that is running so it can control the instructions being run. -- Rich