On Wed, Jan 31, 2018 at 12:44:41PM -0200, Eduardo Habkost wrote:
> Also, if anybody don't like it, users can already specify, e.g.,
> "Broadwell,-hle,-rtm" or "Skylake,+spec_ctrl".
>
> QEMU only adds have the -noTSX and -IBRS CPU for convenience of
> management systems that don't know how to check
On 1/31/2018 2:15 AM, Thomas Gleixner wrote:
Good luck with making all that work.
on the Intel side we're checking what we can do that works and doesn't break
things right now; hopefully we just end up with a bit in the arch capabilities
MSR for "you should do RSB stuffing" and then the HV's c
* Paolo Bonzini (pbonz...@redhat.com) wrote:
> On 29/01/2018 22:13, Andi Kleen wrote:
> >> What happens when someone introduces a
> >> workaround tied to some other model numbers?
> > There are already many of those in the tree for other issues and features.
> > So far you managed to survive witho
On 29/01/2018 22:13, Andi Kleen wrote:
>> What happens when someone introduces a
>> workaround tied to some other model numbers?
> There are already many of those in the tree for other issues and features.
> So far you managed to survive without. Likely that will be true
> in the future too.
"Gue
On Wed, Jan 31, 2018 at 11:15:50AM +0100, Thomas Gleixner wrote:
> On Wed, 31 Jan 2018, Christophe de Dinechin wrote:
> > > On 30 Jan 2018, at 21:46, Alan Cox wrote:
> > >
> > >> If you are ever going to migrate to Skylake, I think you should just
> > >> always tell the guests that you're running
On Wed, Jan 31, 2018 at 02:04:49PM +, Dr. David Alan Gilbert wrote:
> * Borislav Petkov (b...@suse.de) wrote:
> > On Wed, Jan 31, 2018 at 12:30:36PM +, Dr. David Alan Gilbert wrote:
> > > Indeed, it's only for this weird case where you suddenly need to change
> > > it.
> >
> > No, there's
* Borislav Petkov (b...@suse.de) wrote:
> On Wed, Jan 31, 2018 at 12:30:36PM +, Dr. David Alan Gilbert wrote:
> > Indeed, it's only for this weird case where you suddenly need to change
> > it.
>
> No, there's more:
>
> .name = "Broadwell-noTSX",
> .name = "Haswell-noTSX",
Haswel
On Wed, Jan 31, 2018 at 12:30:36PM +, Dr. David Alan Gilbert wrote:
> Indeed, it's only for this weird case where you suddenly need to change
> it.
No, there's more:
.name = "Broadwell-noTSX",
.name = "Haswell-noTSX",
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix
* Borislav Petkov (b...@suse.de) wrote:
> On Wed, Jan 31, 2018 at 11:04:07AM +, Dr. David Alan Gilbert wrote:
> > That half is the easy bit, we've already got that (thanks to Eduardo),
> > QEMU has -IBRS variants of CPU types, so if you start a VM with
> > -cpu Broadwell-IBRS
>
> Eww, a CPU mo
On Wed, Jan 31, 2018 at 11:04:07AM +, Dr. David Alan Gilbert wrote:
> That half is the easy bit, we've already got that (thanks to Eduardo),
> QEMU has -IBRS variants of CPU types, so if you start a VM with
> -cpu Broadwell-IBRS
Eww, a CPU model with a specific feature bit. I hope you guys don
> On 31 Jan 2018, at 11:15, Thomas Gleixner wrote:
>
> On Wed, 31 Jan 2018, Christophe de Dinechin wrote:
>>> On 30 Jan 2018, at 21:46, Alan Cox wrote:
>>>
If you are ever going to migrate to Skylake, I think you should just
always tell the guests that you're running on Skylake. Tha
* Thomas Gleixner (t...@linutronix.de) wrote:
> On Wed, 31 Jan 2018, Christophe de Dinechin wrote:
> > > On 30 Jan 2018, at 21:46, Alan Cox wrote:
> > >
> > >> If you are ever going to migrate to Skylake, I think you should just
> > >> always tell the guests that you're running on Skylake. That w
On Wed, 31 Jan 2018, Christophe de Dinechin wrote:
> > On 30 Jan 2018, at 21:46, Alan Cox wrote:
> >
> >> If you are ever going to migrate to Skylake, I think you should just
> >> always tell the guests that you're running on Skylake. That way the
> >> guests will always assume the worst case sit
> On 30 Jan 2018, at 21:46, Alan Cox wrote:
>
>> If you are ever going to migrate to Skylake, I think you should just
>> always tell the guests that you're running on Skylake. That way the
>> guests will always assume the worst case situation wrt Specte.
>
> Unfortunately if you do that then g
KarimAllah Ahmed writes:
> From: David Woodhouse
>
> Not functional yet; just add the handling for it in the Spectre v2
> mitigation selection, and the X86_FEATURE_IBRS flag which will control
> the code to be added in later patches.
>
> Also take the #ifdef CONFIG_RETPOLINE from around the RSB-
> If you are ever going to migrate to Skylake, I think you should just
> always tell the guests that you're running on Skylake. That way the
> guests will always assume the worst case situation wrt Specte.
Unfortunately if you do that then guest may also decide to use other
Skylake hardware featur
On 01/30/2018 03:56 PM, Christophe de Dinechin wrote:
>
>
>> On 30 Jan 2018, at 15:52, Christian Borntraeger
>> wrote:
>>
>>
>>
>> On 01/30/2018 03:46 PM, Christophe de Dinechin wrote:
>>>
>>>
On 30 Jan 2018, at 13:11, Christian Borntraeger
wrote:
On 01/30/2018
> On 30 Jan 2018, at 15:52, Christian Borntraeger
> wrote:
>
>
>
> On 01/30/2018 03:46 PM, Christophe de Dinechin wrote:
>>
>>
>>> On 30 Jan 2018, at 13:11, Christian Borntraeger
>>> wrote:
>>>
>>>
>>>
>>> On 01/30/2018 01:23 AM, Linus Torvalds wrote:
>>> [...]
So I actuall
On 01/30/2018 03:46 PM, Christophe de Dinechin wrote:
>
>
>> On 30 Jan 2018, at 13:11, Christian Borntraeger
>> wrote:
>>
>>
>>
>> On 01/30/2018 01:23 AM, Linus Torvalds wrote:
>> [...]
>>>
>>> So I actually have a _different_ question to the virtualization
>>> people. This includes the vmwar
> On 30 Jan 2018, at 13:11, Christian Borntraeger
> wrote:
>
>
>
> On 01/30/2018 01:23 AM, Linus Torvalds wrote:
> [...]
>>
>> So I actually have a _different_ question to the virtualization
>> people. This includes the vmware people, but it also obviously
>> incldues the Amazon AWS kind of
On 1/29/2018 7:32 PM, Linus Torvalds wrote:
On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven wrote:
the most simple solution is that we set the internal feature bit in Linux
to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest
in a VM.
That sounds reasonable.
However
On 01/30/2018 01:23 AM, Linus Torvalds wrote:
[...]
>
> So I actually have a _different_ question to the virtualization
> people. This includes the vmware people, but it also obviously
> incldues the Amazon AWS kind of usage.
>
> When you're a hypervisor (whether vmware or Amazon), why do you e
On Mon, Jan 29, 2018 at 07:32:06PM -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven
> wrote:
> >
> > the most simple solution is that we set the internal feature bit in Linux
> > to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest
> > in a V
* Linus Torvalds (torva...@linux-foundation.org) wrote:
> Why do you even _care_ about the guest, and how it acts wrt Skylake?
> What you should care about is not so much the guests (which do their
> own thing) but protect guests from each other, no?
>
> So I'm a bit mystified by some of this dis
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
>
> Note on the unhappiness with some of the patches involved: what I do
> *not* want to see is the "on every kernel entry" kind of garbage.
>
> So my unhappiness with the intel microcode patches is two-fold:
>
> (a) the interface is nast
On Mon, 2018-01-29 at 16:23 -0800, Linus Torvalds wrote:
> And the "big hammer" approach to spectre would seem to
> be to just make sure the BTB and RSB are flushed at vmexit time - and
> even then you might decide that you really want to just move it to
> vmenter time, and only do it if the VM h
On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven wrote:
>
> the most simple solution is that we set the internal feature bit in Linux
> to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest
> in a VM.
That sounds reasonable.
However, wouldn't it be even better to extend on
> Right now, we are dealing with one workaround, which is tied to
> Skylake-era model numbers. Yes, we could report a Skylake model
> number, and Linux guests would use IBRS instead of retpoline. But this
Nobody is planning to use IBRS and Linus has rejected it.
> approach doesn't scale. What hap
On Mon, Jan 29, 2018 at 02:25:12PM -0800, Andi Kleen wrote:
>
> I agree with your point that the common hypervisor practice to fake
> old model numbers will break some of the workarounds. Hypervisors
> may need to revisit their practice.
>
> > > In general, making these kinds of decisions based o
On 1/29/2018 4:23 PM, Linus Torvalds wrote:
Why do you even _care_ about the guest, and how it acts wrt Skylake?
What you should care about is not so much the guests (which do their
own thing) but protect guests from each other, no?
the most simple solution is that we set the internal feature
On Tue, Jan 30, 2018 at 01:20:52AM +, David Dunn wrote:
> Eduardo,
>
> This is why it would be good to have a CPUID bit that says:
> "apply SkyLake RSB stuffing." That's preferable to "trust FMS"
> for VMware.
Agreed it would be more useful than "trust FMS". However, I
believe a "no need to
On Mon, Jan 29, 2018 at 02:12:02PM -0800, Jim Mattson wrote:
> On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost wrote:
> > On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote:
> >> For GCE, "you might be migrated to Skylake" is pretty much a
> >> certainty. Even if you're in a zone that do
Eduardo,
This is why it would be good to have a CPUID bit that says: "apply SkyLake RSB
stuffing." That's preferable to "trust FMS" for VMware.
If Intel defines such a feature flag, sets it on SkyLake, and Linux uses it...
that would be very helpful for VMware.
I won't speak for GCE and AWS.
On Mon, Jan 29, 2018 at 05:10:11PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> The migration code could be 'tickled' (when arrived at the destination)
> to recheck the CPUID and do the alternative logic to turn the
> proper bits on.
>
> And this tickling could be as simple as an ACPI DSDT/AML code
On Mon, Jan 29, 2018 at 02:49:51PM -0800, Jim Mattson wrote:
> And if we expect to introduce Cascade Lake into the pool in the
> future, we use a Cascade Lake model number?
>
> It sounds like you are suggesting that we set the model number to the
> highest model number that will ever be introduced
On Mon, Jan 29, 2018 at 10:29:28PM +, David Dunn wrote:
> On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote:
>
> > Maybe a generic "family/model/stepping/microcode really matches
> > the CPU you are running on" bit would be useful. The bit could
> > be enabled only on host-passthrou
The guest OS is responsible for protecting itself from intra-guest
attacks. The hypervisor can't do that. We want to give the guest OS
the tools it needs to make reasonable decisions about the intra-guest
protections it wants to enable, in an environment where the virtual
processor and the physical
On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse wrote:
>
> On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
>>
>> the objective is to have retpoline be safe everywhere and never use IBRS
>> (Linus was also pretty clear about that) so I'm confused by your question
Note on the unhappines
(Apologies as I was brought into this thread late, but I believe I have
context).
Could a new "feature" be enumerated on Skylake and beyond which specifies that
a particular problem exists which requires different mitigation than on
previous processors? Perhaps a CPUID bit enumerating this featur
And if we expect to introduce Cascade Lake into the pool in the
future, we use a Cascade Lake model number?
It sounds like you are suggesting that we set the model number to the
highest model number that will ever be introduced into the pool, at
any time in the future. That approach would also fai
> Even if we expose bit to indicate that FMS matches the underlying host, when
> does the guest know to query that? The VM can be moved at any point in time,
> including after the guest asks if FMS matches host.
There's no way to enable these mitigations later, so if you always
have to enable t
On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote:
> Maybe a generic "family/model/stepping/microcode really matches
> the CPU you are running on" bit would be useful. The bit could
> be enabled only on host-passthrough (aka "-cpu host") mode.
>
> If we really want to be able to migrat
I agree with your point that the common hypervisor practice to fake
old model numbers will break some of the workarounds. Hypervisors
may need to revisit their practice.
> > In general, making these kinds of decisions based on F/M/S is probably
> > unwise when running in a VM.
>
> Certainly. Th
On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost wrote:
> On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote:
>> For GCE, "you might be migrated to Skylake" is pretty much a
>> certainty. Even if you're in a zone that doesn't currently have
>> Skylake machines, chances are pretty good tha
On Mon, Jan 29, 2018 at 07:44:21PM -0200, Eduardo Habkost wrote:
> On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote:
> >
> >
> > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
> > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
> > > >
> > > > The question is how the h
On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote:
> For GCE, "you might be migrated to Skylake" is pretty much a
> certainty. Even if you're in a zone that doesn't currently have
> Skylake machines, chances are pretty good that it will have Skylake
> machines some day in the not-too-dist
On Mon, Jan 29, 2018 at 09:02:39PM +, David Woodhouse wrote:
>
>
> On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
> > On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
> > >
> > > The question is how the hypervisor could tell that to the guest.
> > > If Intel doesn't give us a CPUID
> The question is about all the additional RSB-frobbing and call depth
> counting and other bits that don't really even exist for Skylake yet in
> a coherent form.
We have had several patch kits posted that all are in a "coherent form"
That was the original one
http://lkml.iu.edu/hypermail/linux
For GCE, "you might be migrated to Skylake" is pretty much a
certainty. Even if you're in a zone that doesn't currently have
Skylake machines, chances are pretty good that it will have Skylake
machines some day in the not-too-distant future.
In general, making these kinds of decisions based on F/M
On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote:
> On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
> >
> > The question is how the hypervisor could tell that to the guest.
> > If Intel doesn't give us a CPUID bit that can be used to tell
> > that retpolines are enough, maybe we should us
On 1/29/2018 12:42 PM, Eduardo Habkost wrote:
The question is how the hypervisor could tell that to the guest.
If Intel doesn't give us a CPUID bit that can be used to tell
that retpolines are enough, maybe we should use a hypervisor
CPUID bit for that?
the objective is to have retpoline be saf
On Mon, Jan 29, 2018 at 08:17:02PM +, David Woodhouse wrote:
> On Mon, 2018-01-29 at 18:14 -0200, Eduardo Habkost wrote:
> >
> > Sorry for being confused here, as probably the answer is buried
> > on a LKML thread somewhere. The comment explains what the code
> > does, but not why. Why exact
On Mon, 2018-01-29 at 18:14 -0200, Eduardo Habkost wrote:
>
> Sorry for being confused here, as probably the answer is buried
> on a LKML thread somewhere. The comment explains what the code
> does, but not why. Why exactly IBRS is preferred on Skylake?
>
> I'm asking this because I would like
On Sat, Jan 20, 2018 at 08:22:56PM +0100, KarimAllah Ahmed wrote:
> From: David Woodhouse
>
> Not functional yet; just add the handling for it in the Spectre v2
> mitigation selection, and the X86_FEATURE_IBRS flag which will control
> the code to be added in later patches.
>
> Also take the #if
On Wed, 2018-01-24 at 07:09 -0800, Arjan van de Ven wrote:
> On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote:
> > Arjan, why do you think this can only be done as a whitelist?
>
> I suggested a minimum version list for those cpus that need it.
>
> microcode versions are tricky (and we've released be
On 1/24/2018 1:10 AM, Greg Kroah-Hartman wrote:
That means the whitelist ends up basically empty right now. Should I
add a command line parameter to override it? Otherwise we end up having
to rebuild the kernel every time there's a microcode release which
covers a new CPU SKU (which is why I ki
On Wed, 2018-01-24 at 13:29 +0100, Peter Zijlstra wrote:
>
> Yes :/
>
> We could look at extending x86_cpu_id and x86_match_cpu with a stepping
> option I suppose, but that might be lots of churn.
That goes all the way to mod_deviceinfo, and would be horrid.
We could add an x86_match_cpu_steppi
On Wed, 2018-01-24 at 08:49 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 24 Jan 2018, David Woodhouse wrote:
> >
> > I'm kind of tempted to turn it into a whitelist just by adding 1 to the
> > microcode revision in each table entry. Sure, that N+1 might be another
> > microcode build that a
On Wed, Jan 24, 2018 at 12:14:51PM +, David Woodhouse wrote:
> On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> >
> > Typically tglx likes to use x86_match_cpu() for these things; see also
> > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> > errata").
>
> Ewww.
>
On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
>
> Typically tglx likes to use x86_match_cpu() for these things; see also
> commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> errata").
Ewww.
static u32 hsx_deadline_rev(void)
{
switch (boot_cpu_data.x86_mask) {
On Wed, 24 Jan 2018, David Woodhouse wrote:
> I'm kind of tempted to turn it into a whitelist just by adding 1 to the
> microcode revision in each table entry. Sure, that N+1 might be another
> microcode build that also has issues but never saw the light of day...
Watch out for the (AFAIK) still n
> > > + for (i = 0; i < ARRAY_SIZE(spectre_bad_microcodes); i++) {
> > > + if (c->x86_model == spectre_bad_microcodes[i].model &&
> > > + c->x86_mask == spectre_bad_microcodes[i].stepping)
> > > + return (c->microcode <=
> > > spectre_bad_microcodes[i].microcode
On Wed, Jan 24, 2018 at 09:02:21AM +, David Woodhouse wrote:
> On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> > Typically tglx likes to use x86_match_cpu() for these things; see also
> > commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> > errata").
>
> Thanks, will
On Wed, 2018-01-24 at 09:47 +0100, Peter Zijlstra wrote:
> Typically tglx likes to use x86_match_cpu() for these things; see also
> commit: bd9240a18edfb ("x86/apic: Add TSC_DEADLINE quirk due to
> errata").
Thanks, will fix. I think we might also end up in whitelist mode,
adding "known good" micr
On Tue, Jan 23, 2018 at 08:58:36PM +, David Woodhouse wrote:
> +static const struct sku_microcode spectre_bad_microcodes[] = {
> + { INTEL_FAM6_KABYLAKE_DESKTOP, 0x0B, 0x80 },
> + { INTEL_FAM6_KABYLAKE_MOBILE, 0x0A, 0x80 },
> + { INTEL_FAM6_KABYLAKE_MOBILE, 0x0A, 0x80 },
> + {
On Sun, 2018-01-21 at 15:31 +0100, Thomas Gleixner wrote:
> >
> > XX: Do we want a microcode blacklist?
>
> Oh yes, we want a microcode blacklist. Ideally we refuse to load the
> affected microcode in the first place and if its already loaded then at
> least avoid to use the borked features.
>
>
On Mon, 2018-01-22 at 14:30 +0100, Greg Kroah-Hartman wrote:
> We kind of do, you can submit patches to UEFI, but I doubt that the
> processor-specific portions are actually present in the Tianocore code
> to be able to be patched.
This is just about which microcode your BIOS loads into the CPU be
On Mon, Jan 22, 2018 at 01:06:18PM +0100, Borislav Petkov wrote:
> On Mon, Jan 22, 2018 at 10:51:53AM +0100, Peter Zijlstra wrote:
> > That wouldn't be enough; AFAIU there's people with this stuff already
> > flashed in their BIOS. So the kernel needs to deal with it one way or
> > another.
>
> No
On Mon, Jan 22, 2018 at 10:51:53AM +0100, Peter Zijlstra wrote:
> That wouldn't be enough; AFAIU there's people with this stuff already
> flashed in their BIOS. So the kernel needs to deal with it one way or
> another.
Not a lot we can do there except maybe disable IBRS on those and users
can go a
On Sun, Jan 21, 2018 at 03:56:55PM +0100, Borislav Petkov wrote:
> Also, blacklisting microcode for early loading will become an ugly dance
> so I'd like to avoid it if possible.
>
> Thus, it would be much much easier if dracut/initrd creation thing
> already filters those blacklisted blobs by loo
> On Sat, 20 Jan 2018, KarimAllah Ahmed wrote:
>> From: David Woodhouse
>>
>> Not functional yet; just add the handling for it in the Spectre v2
>> mitigation selection, and the X86_FEATURE_IBRS flag which will control
>> the code to be added in later patches.
>>
>> Also take the #ifdef CONFIG_RE
On Sun, Jan 21, 2018 at 03:31:28PM +0100, Thomas Gleixner wrote:
> Oh yes, we want a microcode blacklist. Ideally we refuse to load the
> affected microcode in the first place and if its already loaded then at
> least avoid to use the borked features.
>
> PR texts promising that Intel is committed
On Sat, 20 Jan 2018, KarimAllah Ahmed wrote:
> From: David Woodhouse
>
> Not functional yet; just add the handling for it in the Spectre v2
> mitigation selection, and the X86_FEATURE_IBRS flag which will control
> the code to be added in later patches.
>
> Also take the #ifdef CONFIG_RETPOLINE
From: David Woodhouse
Not functional yet; just add the handling for it in the Spectre v2
mitigation selection, and the X86_FEATURE_IBRS flag which will control
the code to be added in later patches.
Also take the #ifdef CONFIG_RETPOLINE from around the RSB-stuffing; IBRS
mode will want that too.
74 matches
Mail list logo
