It's unclear from Intel's documentation whether writing bit 0 of
IA32_SPEC_CTRL or bit 0 of IA32_PRED_CMD will flush the BHB. (At
least, it's unclear from the documentation I have.)
The retpoline patches include code for *filling* the RSB, but if you
invoke the RSB refill code from kernel text bef
On 09/01/2018 21:39, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote:
>> On 09/01/2018 17:23, Arjan van de Ven wrote:
>>> On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
On 09/01/2018 16:19, Arjan van de Ven wrote:
> On 1/9/2018 7:00 AM, Liran Alon wr
On 09/01/2018 21:57, Jim Mattson wrote:
> Before VM-entry, don't we need to flush the BHB and the RSB to avoid
> revealing KASLR information to the guest? (Thanks to Liran for
> pointing this out.)
I don't know how you flush the BHB? As to the RSB, that would also be
part of generic Linux code so
If my documentation is up-to-date, writing IBRS does not clear the RSB
(except for parts which contain an RSB that is not filled by 32
CALLs).
On Tue, Jan 9, 2018 at 1:11 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 09, 2018 at 12:57:38PM -0800, Jim Mattson wrote:
>> Before VM-entry, don't we n
On Tue, Jan 09, 2018 at 12:57:38PM -0800, Jim Mattson wrote:
> Before VM-entry, don't we need to flush the BHB and the RSB to avoid
> revealing KASLR information to the guest? (Thanks to Liran for
> pointing this out.)
Exactly.
Or is is touching with any value good enough?
(Removing 't...@char.u
Before VM-entry, don't we need to flush the BHB and the RSB to avoid
revealing KASLR information to the guest? (Thanks to Liran for
pointing this out.)
On Tue, Jan 9, 2018 at 12:47 PM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 09, 2018 at 03:39:09PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Tue,
On Tue, Jan 09, 2018 at 03:39:09PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote:
> > On 09/01/2018 17:23, Arjan van de Ven wrote:
> > > On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
> > >> On 09/01/2018 16:19, Arjan van de Ven wrote:
> > >>> On 1/9
On Tue, Jan 09, 2018 at 05:49:08PM +0100, Paolo Bonzini wrote:
> On 09/01/2018 17:23, Arjan van de Ven wrote:
> > On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
> >> On 09/01/2018 16:19, Arjan van de Ven wrote:
> >>> On 1/9/2018 7:00 AM, Liran Alon wrote:
>
> - ar...@linux.intel.com wrote:
On 09/01/2018 17:23, Arjan van de Ven wrote:
> On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
>> On 09/01/2018 16:19, Arjan van de Ven wrote:
>>> On 1/9/2018 7:00 AM, Liran Alon wrote:
- ar...@linux.intel.com wrote:
> On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
>> The above ("IB
On 1/9/2018 8:17 AM, Paolo Bonzini wrote:
On 09/01/2018 16:19, Arjan van de Ven wrote:
On 1/9/2018 7:00 AM, Liran Alon wrote:
- ar...@linux.intel.com wrote:
On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
The above ("IBRS simply disables the indirect branch predictor") was my
take-away messag
On 09/01/2018 16:19, Arjan van de Ven wrote:
> On 1/9/2018 7:00 AM, Liran Alon wrote:
>>
>> - ar...@linux.intel.com wrote:
>>
>>> On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
The above ("IBRS simply disables the indirect branch predictor") was my
take-away message from private discussion
- ar...@linux.intel.com wrote:
> >> I'm sorry I'm not familiar with your L0/L1/L2 terminology
> >> (maybe it's before coffee has had time to permeate the brain)
> >
> > These are standard terminology for guest levels:
> > L0 == hypervisor that runs on bare-metal
> > L1 == hypervisor that run
I'm sorry I'm not familiar with your L0/L1/L2 terminology
(maybe it's before coffee has had time to permeate the brain)
These are standard terminology for guest levels:
L0 == hypervisor that runs on bare-metal
L1 == hypervisor that runs as L0 guest.
L2 == software that runs as L1 guest.
(We ar
- ar...@linux.intel.com wrote:
> On 1/9/2018 7:00 AM, Liran Alon wrote:
> >
> > - ar...@linux.intel.com wrote:
> >
> >> On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
> >>> The above ("IBRS simply disables the indirect branch predictor")
> was
> >> my
> >>> take-away message from private dis
On 1/9/2018 7:00 AM, Liran Alon wrote:
- ar...@linux.intel.com wrote:
On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
The above ("IBRS simply disables the indirect branch predictor") was
my
take-away message from private discussion with Intel. My guess is
that
the vendors are just handwavi
- ar...@linux.intel.com wrote:
> On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
> > The above ("IBRS simply disables the indirect branch predictor") was
> my
> > take-away message from private discussion with Intel. My guess is
> that
> > the vendors are just handwaving a spec that doesn't match
On 1/9/2018 3:41 AM, Paolo Bonzini wrote:
The above ("IBRS simply disables the indirect branch predictor") was my
take-away message from private discussion with Intel. My guess is that
the vendors are just handwaving a spec that doesn't match what they have
implemented, because honestly a microc
On 09/01/2018 12:31, Liran Alon wrote:
>> On current generation processors, as I understand it, IBRS simply
>> disables the indirect branch predictor when set to 1. Therefore,
>> as
> This is not how I understood what IBRS does.
>
> Intel (not sure about AMD) states that if IBRS is set, indirect
- pbonz...@redhat.com wrote:
> On 08/01/2018 21:00, Liran Alon wrote:
> >
> >
> > On 08/01/18 20:08, Paolo Bonzini wrote:
> >> From: Tom Lendacky
> >>
> >> Set IBPB (Indirect Branch Prediction Barrier) when the current CPU
> is
> >> going to run a VCPU different from what was previously ru
On 08/01/2018 21:00, Liran Alon wrote:
>
>
> On 08/01/18 20:08, Paolo Bonzini wrote:
>> From: Tom Lendacky
>>
>> Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is
>> going to run a VCPU different from what was previously run. Nested
>> virtualization uses the same VMCB for t
On 08/01/18 20:08, Paolo Bonzini wrote:
From: Tom Lendacky
Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is
going to run a VCPU different from what was previously run. Nested
virtualization uses the same VMCB for the second level guest, but the
L1 hypervisor should be us
From: Tom Lendacky
Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is
going to run a VCPU different from what was previously run. Nested
virtualization uses the same VMCB for the second level guest, but the
L1 hypervisor should be using IBRS to protect itself.
Signed-off-by:
22 matches
Mail list logo