> From: Paolo Bonzini
> Sent: Thursday, May 3, 2018 5:20 PM
>
> On 03/05/2018 03:27, Wanpeng Li wrote:
> > So for 1) guest->guest attacks 2) guest/ring3->host/ring3 attacks 3)
> > guest/ring0->host/ring0 attacks, if IBPB is enough to protect these
> > three scenarios and retpoline is not needed?
>
2018-05-03 17:19 GMT+08:00 Paolo Bonzini :
> On 03/05/2018 03:27, Wanpeng Li wrote:
>> So for 1) guest->guest attacks 2) guest/ring3->host/ring3 attacks 3)
>> guest/ring0->host/ring0 attacks, if IBPB is enough to protect these
>> three scenarios and retpoline is not needed?
>
> In theory yes, in pr
On 03/05/2018 03:27, Wanpeng Li wrote:
> So for 1) guest->guest attacks 2) guest/ring3->host/ring3 attacks 3)
> guest/ring0->host/ring0 attacks, if IBPB is enough to protect these
> three scenarios and retpoline is not needed?
In theory yes, in practice if you want to do that IBPB is much more
exp
Hi Ashok，
2018-02-02 5:59 GMT+08:00 KarimAllah Ahmed :
> From: Ashok Raj
>
> The Indirect Branch Predictor Barrier (IBPB) is an indirect branch
> control mechanism. It keeps earlier branches from influencing
> later ones.
>
> Unlike IBRS and STIBP, IBPB does not define a new mode of operation.
> I
> > + wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB);
>
> Should this be wrmsrl_safe? I don't see where we've verified host
> support of this MSR.
In mainline all wrmsr are wrmsrl_safe now.
-Andi
On Thu, Feb 1, 2018 at 1:59 PM, KarimAllah Ahmed wrote:
> @@ -3684,6 +3696,22 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct
> msr_data *msr)
> case MSR_IA32_TSC:
> kvm_write_tsc(vcpu, msr);
> break;
> + case MSR_IA32_PRED_CMD:
> +
On 02/02/2018 21:28, Konrad Rzeszutek Wilk wrote:
Nothing would *set* the IBPB bit though, since that's a "virtual" bit
on Intel hardware. The comment explains why we have that |= F(IBPB),
and if the comment wasn't true, we wouldn't need that code either.
>>> But this seems wrong. Th
On 02/02/2018 21:52, Alan Cox wrote:
>>> No. The AMD feature bits give us more fine-grained support for exposing
>>> IBPB or IBRS alone, so we expose those bits on Intel too.
>> But but.. that runs smack against the idea of exposing a platform that
>> is as close to emulating the real hardware as
On Fri, Feb 02, 2018 at 08:31:27PM +, David Woodhouse wrote:
> On Fri, 2018-02-02 at 15:28 -0500, Konrad Rzeszutek Wilk wrote:
> >
> > >
> > > No. The AMD feature bits give us more fine-grained support for exposing
> > > IBPB or IBRS alone, so we expose those bits on Intel too.
> >
> > But b
> > No. The AMD feature bits give us more fine-grained support for exposing
> > IBPB or IBRS alone, so we expose those bits on Intel too.
>
> But but.. that runs smack against the idea of exposing a platform that
> is as close to emulating the real hardware as possible.
Agreed, and it's asking
On Fri, 2018-02-02 at 15:28 -0500, Konrad Rzeszutek Wilk wrote:
>
> >
> > No. The AMD feature bits give us more fine-grained support for exposing
> > IBPB or IBRS alone, so we expose those bits on Intel too.
>
> But but.. that runs smack against the idea of exposing a platform that
> is as close
On Fri, Feb 02, 2018 at 08:16:15PM +, David Woodhouse wrote:
>
>
> On Fri, 2018-02-02 at 14:56 -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Feb 02, 2018 at 06:02:24PM +, David Woodhouse wrote:
> > >
> > > On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote:
> > > >
> > > >
On Fri, 2018-02-02 at 14:56 -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 02, 2018 at 06:02:24PM +, David Woodhouse wrote:
> >
> > On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote:
> > >
> > > >
> > > > @@ -625,7 +629,12 @@ static inline int __do_cpuid_ent(struct
> > > >
On Fri, Feb 02, 2018 at 06:02:24PM +, David Woodhouse wrote:
> On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote:
> > > @@ -625,7 +629,12 @@ static inline int __do_cpuid_ent(struct
> > > kvm_cpuid_entry2 *entry, u32 function,
> > > if (!g_phys_as)
> > >
On Fri, 2018-02-02 at 12:49 -0500, Konrad Rzeszutek Wilk wrote:
> > @@ -625,7 +629,12 @@ static inline int __do_cpuid_ent(struct
> > kvm_cpuid_entry2 *entry, u32 function,
> > if (!g_phys_as)
> > g_phys_as = phys_as;
> > entry->eax = g_phys_as
On Thu, Feb 01, 2018 at 10:59:43PM +0100, KarimAllah Ahmed wrote:
> From: Ashok Raj
>
> The Indirect Branch Predictor Barrier (IBPB) is an indirect branch
> control mechanism. It keeps earlier branches from influencing
> later ones.
>
> Unlike IBRS and STIBP, IBPB does not define a new mode of o
From: Ashok Raj
The Indirect Branch Predictor Barrier (IBPB) is an indirect branch
control mechanism. It keeps earlier branches from influencing
later ones.
Unlike IBRS and STIBP, IBPB does not define a new mode of operation.
It's a command that ensures predicted branch targets aren't used after
17 matches
Mail list logo
