> > It is a reasonable approach. Let a process who needs max security
> > opt in with disabled dumpable. It can have a flush with IBPB clear before
> > starting to run, and have STIBP set while running.
> >
>
> Do we maybe want a separate opt in? I can easily imagine things like
> web browsers
k, Asit K
> ; rkrc...@redhat.com; karah...@amazon.de;
> h...@zytor.com; mi...@redhat.com; Nakajima, Jun
> ; x...@kernel.org; Raj, Ashok ;
> Van De Ven, Arjan ; tim.c.c...@linux.intel.com;
> pbonz...@redhat.com; a...@linux.intel.com; linux-kernel@vger.kernel.org;
> dw...@in
> On SKL+ retpoline is mostly there, but has a few dinky holes in and it
> _might_ make sense to use IBRS.
>
> But I feel it needs explaining what the exact holes are (pjt and dwmw2
> had a fair enumeration IIRC) such that people can judge the risk.
you are correct to need and want this.
the pro
> > We were also worried about the indirect calls that are part of the
> > paravirt interfaces when retpolines are not in place.
> >
>
> How could those possibly be any worse than any other indirect call in
> the kernel?
they're worse if they happen before you write the MSR that then protects th
> > The RSB filling macro is applicable to AMD, and, if software is unable to
> > verify that lfence is serializing on AMD (possible when running under a
> > hypervisor), the generic retpoline support will be used and, so, is also
> > applicable to AMD. Change the use of pause to lfence.
> >
> > S
> > When the a module hasn't been compiled with a retpoline
> > aware compiler, print a warning and set a taint flag.
>
> Isn't that caught by the "build with a different compiler/version" check
> that we have? Or used to have? If not, can't we just make it into that
> type of check to catch thi
> > Anyway, I do think the patches I've seen so far are ok, and the real
> > reason I'm writing this email is actually more about future patches:
> > do we have a good handle on where these array index sanitations will
> > be needed?
the obvious cases are currently obviously being discussed.
but
> > short term there was some extremely rudimentary static analysis done.
> > clearly
> > that has extreme limitations both in insane rate of false positives, and
> > missing
> > cases.
>
> What was the output roughly, how many suspect places that need
> array_idx_nospec()
> handling: a few, a f
> On Wed, Jan 31, 2018 at 8:55 AM, Paolo Bonzini wrote:
>
> > In fact this MSR can even be passed down unconditionally, since it needs
> > no save/restore and has no ill performance effect on the sibling
> > hyperthread.
>
> I'm a bit surprised to hear that IBPB has no ill performance impact on
> Enabling IBRS does not prevent software from controlling the predicted
> targets of indirect branches of unrelated software executed later at
> the same predictor mode (for example, between two different user
> applications, or two different virtual machines). Such isolation can
> be ensured thro
: Hou Tao ; aarca...@redhat.com; linux-
> ker...@vger.kernel.org; Van De Ven, Arjan
> Cc: mi...@redhat.com; Thomas Gleixner ;
> a...@linux.intel.com; dave.han...@linux.intel.com; pet...@infradead.org;
> qiuxi...@huawei.com; wangkefeng.w...@huawei.com
> Subject: Re: [RH72 Spectre] ibpb_
> On Thu, Jan 4, 2018 at 11:19 AM, David Woodhouse
> wrote:
> >
> > On Skylake the target for a 'ret' instruction may also come from the
> > BTB. So if you ever let the RSB (which remembers where the 'call's came
> > from get empty, you end up vulnerable.
>
> That sounds like it could cause mispr
> > So long as the underlying binary satisfies the precondition that it
> > will not underflow its own RSB.
> >
> > Then we if we subsequently guarantee never to _reduce_ the number of
> > entries in its RSB at any point remote to its own execution, then the
> > precondition is preserved and underf
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, January 05, 2018 3:32 AM
> To: Van De Ven, Arjan ; Linus Torvalds
> ; David Woodhouse
> Cc: Tim Chen ; Thomas Gleixner
> ; Andy Lutomir
>
> Doing a huge amount of work with reptoline and then you find SMM is
> called reproducibly somehow and a new PoC could exist for it, not fun.
retpoline we want for broadwell and earlier anyway..
I'm sorry but your whole statement reeks a little bit of "perfect is the enemy
of good"
> On Fri, Jan 05, 2018 at 04:37:30PM +, David Woodhouse wrote:
> > You are completely ignoring pre-Skylake here.
> >
> > On pre-Skylake, retpoline is perfectly sufficient and it's a *lot*
> > faster than the IBRS option which is almost prohibitively slow.
> >
> > We didn't do it just for fun. A
> >> .macro DISABLE_IBRS
> >> - ALTERNATIVE "jmp .Lskip_\@", "", X86_FEATURE_SPEC_CTRL
> >> + testl $1, dynamic_ibrs
> > On every system call we end up hammering on this 'dynamic_ibrs'
> > variable. And it looks like it can be flipped via the IPI mechanism.
> >
> > Would it make sense for this
> I agree. But this is what customers are told to inspect to see if they
> are impacted. And if in the future versions this goes away or such - they
> will freak out and cause needless escalations.
it's a mistake though... retpoline is what people should be using
... and only in super except
> > it's a mistake though... retpoline is what people should be using
> > ... and only in super exception cases should IBRS even be considered
>
> Like on certain Skylake and Broadwell where using the retpoline won't suffice?
skylake is a bit more complex but that was discussed in earlier e
> > + if ((!c->cpu_index) && (boot_cpu_has(X86_FEATURE_SPEC_CTRL))) {
>
> We should test X86_BUG_SPECTRE_V1 here too before default enabling this,
> no?
we shouldn't default enable this.
> On Fri, 2018-01-26 at 10:12 -0800, Arjan van de Ven wrote:
> > On 1/26/2018 10:11 AM, David Woodhouse wrote:
> > >
> > > I am *actively* ignoring Skylake right now. This is about per-SKL
> > > userspace even with SMEP, because we think Intel's document lies to us.
> >
> > if you think we lie to y
> > you asked before and even before you sent the email I confirmed to
> > you that the document is correct
> >
> > I'm not sure what the point is to then question that again 15 minutes
> > later other than creating more noise.
>
> Apologies, I hadn't seen the comment on IRC.
>
> Sometimes the do
>
> On Sun, 2018-01-28 at 12:40 -0800, Andy Lutomirski wrote:
> >
> > Do you mean that the host would intercept the guest WRMSR and do
> > WRMSR itself? I would suggest that doing so is inconsistent with the
> > docs. As specified, doing WRMSR to write 1 to IBRS does *not*
> > protect the guest.
> On 29/01/2018 01:58, KarimAllah Ahmed wrote:
> > Add direct access to MSR_IA32_SPEC_CTRL for guests. Future intel processors
> > will use this MSR to indicate RDCL_NO (bit 0) and IBRS_ALL (bit 1).
>
> This has to be customizable per-VM (similar to the patches Amazon posted
> a while ago for UCOD
> I just sent a v3 that changes the VERMAGIC only, based on Greg's
> earlier feedback.
>
> It has the drawbacks that it:
> - refuses loading instead of warns
> - doesn't stop refusing when the feature is runtime disabled
>
> But it's much simpler, just a few lines of ifdef.
I think simple is goo
> In other words, if you use late microcode loading for getting IBRS, you
> don't get ALTERNATIVE patching and its benefits?
>
> I'll also profess some microcode ignorance here. Is "late microcode
> patching" *all* of the stuff we do from the OS, or do we have early and
> late Linux loading in
> On Wed, Jan 10, 2018 at 12:12:53PM +, David Woodhouse wrote:
> > IBRS is like a barrier. You must write it between the 'problematic'
> > loading of the branch targets, and the kernel code which might be
> > affected.
> >
> > You cannot, on current hardware, merely set it once and forget abo
> Andrea, what you're saying is directly contradicting what I've heard
> from Intel.
>
> The documentation already distinguishes between IBRS on current
> hardware, and IBRS_ATT on future hardware. If it was the case that IBRS
> on current hardware is a set-and-forget option and completely disab
> So here is the simple list of questions all to be answered with YES or
> NO. I don't want to see any of the 'but, though ...'. We all know by now
> that it's CPU dependent and slow and whatever and that IBRS_ATT will be in
> future CPUs. So get your act together and tell a clear YES or NO.
I wil
> ibrs_enabled 2:
>
> sets IBRS always in host
this is not secure
> This matches the semantics described here by Tim patchset on lkml:
>
> https://marc.info/?l=linux-kernel&m=151520606320646
I will talk to Tim, it's not right.
> I can tell in practice it works as I described in all microco
> Hello,
>
> On Wed, Jan 10, 2018 at 02:46:22PM +0100, Thomas Gleixner wrote:
> > So here is the simple list of questions all to be answered with YES or
> > NO. I don't want to see any of the 'but, though ...'. We all know by now
> > that it's CPU dependent and slow and whatever and that IBRS_ATT
> > For modules it is checked at compile time, however it cannot
> > check assembler or other non compiled objects used in the module link.
>
> It is not unlikely that most of a module's code is released as a
> binary 'blob', with only the part that needs to match the kernel ABI
> compiled on the
> Having firmware refill the RSB only makes a difference if you are on
> Skylake+ were RSB underflows are bad, and you're not using IBRS to
> protect your indirect predictions.
... and before that you don't need it.
> Ok,
>
> I actually tested boot time with my patch and didn't see a difference
> (so I guess our first attempt to send messages usually succeeds) but if
> we're concearned about less-than-a-second boot time we'd rather keep the
> microseonds delay for first several attempts. I'll do v2.
of cours
> >> For bonus points: What should happen to a VM that is live migrated
> >> from one hypervisor to another, and the hypervisors have different
> >> IBRS support?
> >
> > Doctor Doctor it hurts when I do this
> >
> > Migration tends to only work between HV's that are relatively
> > homogeneous
> > I meant software wise. You're not going to live migrate from xen to
> > kvm or backwards. or between very radically different versions of the
> > kvm stack.
>
> Forwards migration to a radically newer version certainly happens. So
> when the source hypervisor was too old to tell the VM about
> > In the past the only guidance was to not load microcode at the same time to
> the
> > thread siblings of a core. We now have new guidance that the sibling must be
> > spinning and not doing other things that can introduce instability around
> loading
> > microcode.
>
> Document that properly
> To add a bit more to this, Intel just updated their
> IA32_ARCH_CAPABILITIES_MSR
> to have a new bit to sample to figure out whether you need IBRS or not
> during runtime.
actually we updated the document when you need RSB stuffing.
based on the request of various folks here on LKML.
>
> >>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the
> >>> (now emulated) MSR on every kernel entry/exit, that's *still* going to
> >>> be a metric shitload faster than what it *thought* it was doing.
>
> Is there any indication/log to the admin that VM doesn't know about
> On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
>
> > the guest is not the problem; guests obviously will already honor if
> > Enhanced
> > IBRS is enumerated. The problem is mixed migration pools where the
> hypervisor
> > may need to
> > On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox
> wrote:
> > >
> > > In theory there's nothing stopping a guest getting a 'you are about to
> > > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
> > > removed.
> >
> > I'm not convinced we handle the case of hotplug CPU's with
> > Raw diff between the mainline blacklist and the bulletin looks like:
> > @@ -1,5 +1,6 @@
> > { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 },
> > { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b },
> > +{ INTEL_FAM6_BROADWELL_X,0x01, 0x0b23 },
> > { INTEL_FAM6_BROADWELL_X,0x01,
42 matches
Mail list logo
