From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-183342-garchives=archives.gentoo.org@lists.gentoo.org>
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 0CA4E1382C5
for <garchives@archives.gentoo.org>; Thu, 5 Apr 2018 16:54:16 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 452D2E0996;
Thu, 5 Apr 2018 16:54:08 +0000 (UTC)
Received: from mail-pl0-x244.google.com (mail-pl0-x244.google.com [IPv6:2607:f8b0:400e:c01::244])
(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 B25DDE092C
for <gentoo-user@lists.gentoo.org>; Thu, 5 Apr 2018 16:54:07 +0000 (UTC)
Received: by mail-pl0-x244.google.com with SMTP id s10-v6so18003333plp.0
for <gentoo-user@lists.gentoo.org>; Thu, 05 Apr 2018 09:54:07 -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=AHqN7oA0qzaQkcz+/kQP8eGHscOAjK1fef7C6a6bktw=;
b=dO8jENBkhrMyV/sUp1OXgh7J0EEA70GnMFm8FBm2HCD7j/x59xDNubkPuQYhxQS0Vk
uF2ghneyWH7N7LBerLbEn5UIVIuB4vQ/o9Zdjd9wgQ/ig+yNfqFVADVSk9u0tkSNt+V7
twVMmhiCF9u1GwxfrYIlrmfEFSqEA4MaU8Z1oa7lZln/m0PdjnbvSBJBaWZk79ofzLty
b1PIGp1RQYdCEEdFJ8T0KHVx1i8cwaemsL/BVy2SshIWCsDdC4gUtT7QxeFISrjqLF36
WK3BLH4WKHTUKxDO3Z/JGkgT2O8/KSQuwLGkNMcIY439SoApaYBGtEykyO1K7zHCnMa5
oZvQ==
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=AHqN7oA0qzaQkcz+/kQP8eGHscOAjK1fef7C6a6bktw=;
b=YHEkoZVtgvCzELVPIkEgscrVUYly7iPkkdznNSANLEZY0rxDLz0HyY8ynu4M1Daipw
RT8IQsyv2+/kYyXgAfOTP3ewQpEZmT1PNsAvIfsQNKd2JeNbs214HaFfBnRPRJgyRj62
Sug7dz/eM03bHUIXwcmcsNKXeBsO8UE0mSDbvhAwH78pPE13x8/T0QXHQj9FjzltTKYz
HTIvtz+3kMsFiKugBzDlzdVyOl6hpg9SsLq3p4+TVI2PsMWpELmgGLMHeR9TspbGZ2c2
Kxlhqm3/Jx9aTYI/ewlKONOwFvcQAbaZ7kmmDm69Nws2HWLzbU6gLbqTWN0dN11eIOPA
/I9w==
X-Gm-Message-State: AElRT7HNnLg96gCm0Vep6OvSQfbFGbc045wSaLoN31Ggwav1mqK56aES
iNmal+GD2rL5mBK7RwFD1mTx6OI6kDuiR4Htv6iQwQ==
X-Google-Smtp-Source: AIpwx4/np9AiJLvLpoKkLu/vZUVGKVDmUJOH3CO+p4AePMe9r72F7u88MlkysO+XOOvPi9xrpWJ05obj9IuJnf6HGyc=
X-Received: by 2002:a17:902:8e86:: with SMTP id bg6-v6mr23358816plb.91.1522947245894;
Thu, 05 Apr 2018 09:54:05 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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 09:54:05 -0700 (PDT)
In-Reply-To: <8105793.sl6g6gt1vY@dell_xps>
References: <CAC=wYCGz2duRAX01TLu5RMqpTC-cQ74SJyhsTNinkk5PRePtxA@mail.gmail.com>
<8105793.sl6g6gt1vY@dell_xps>
From: Rich Freeman <rich0@gentoo.org>
Date: Thu, 5 Apr 2018 12:54:05 -0400
X-Google-Sender-Auth: s0-4iizs6L-IlPVkXedyui6KMU8
Message-ID: <CAGfcS_k8ZOAHHKswt53hbOVtRKkb2sWR0dsPZFy2d=SHT9w1GA@mail.gmail.com>
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: 0fe6d372-947c-4008-9163-4c03ef7db12a
X-Archives-Hash: 9f8fdb026e96e79d92bd87848e65cc3d
On Thu, Apr 5, 2018 at 12:34 PM, Mick <michaelkintzios@gmail.com> wrote:
>
> Does the lack of a microcode patch mean the in-kernel and other software fixes
> won't be sufficient to protect PCs running these old CPUs?
I'm interested if somebody has a more informed answer, but my guess is
that it would result in a less efficient fix being applied by the
kernel.
I'm not sure if Intel actually has any good fixes for meltdown in
microcode. The in-kernel fix for that is fairly expensive, and if it
could be fixed in microcode that would be a big savings (assuming the
microcode didn't add a cost).
My understanding is that most of the microcode patches are for spectre
and modify the behavior of lfence to block vulnerable speculative
execution. This still has some cost to it, but it is minimal.
Without the microcode fix I imagine the vulnerabilities could still be
fixed via retpolines and similar techniques, at a higher cost. 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.
I haven't read up on what has changed in the last month or two, but
the gist of it is that with spectre you have three options:
1. Ignore it. Some code is vulnerable. No performance cost.
2. Add a series of instructions to vulnerable code so that
speculative execution is blocked on any processor. The code is no
longer vulnerable, but those instructions can add some cost (not as
bad as with meltdown).
3. If the CPU+microcode supports it, add a single lfence instruction
to vulnerable code. This will address the vulnerability at a lower
cost.
In an ideal world we wouldn't need #2. That would not only make the
fixes perform better, but it would also mean that compilers wouldn't
have to generate code that figures out whether scenario 2 vs 3 applies
AT RUNTIME and do the right thing.
Now, if 95% of users fall into bucket 3 and 5% fall into bucket 2 you
have an interesting situation. Will software developers take the time
to ensure that scenario #2 is even covered, except for the most
at-risk code (such as browser sandboxes)?
Granted, I think in reality an awful lot of software will just fall
into bucket #1 for the same reason that we STILL keep finding buffer
overflows. That, and people will think of new situations where
spectre applies that aren't presently known. I don't think we're at a
point where a compiler can reliably determine whether a
retpoline/lfence is actually needed. The last time I checked the GCC
fixes needed the code to be tagged in some way to tell it to add the
protection (when you think about it C doesn't even do bounds checks,
let alone figure out when you're about to do a dangerous one).
--
Rich