I looked into these changes after a while again. I will split this
larger commit into smaller ones, and address parts of the problem in
each of them separately.
On 3/29/19 18:11, Jan Beulich wrote:
On 14.03.19 at 13:50, wrote:
>> Guests can issue grant table operations and provide guest cont
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v1: split the gnttab commit of the previous L1TF series into multiple commits
xen/common/grant_table.c | 33 +
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/xen/common
of the current table are not addressed in this
commit.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v1: adapt the comments for shared_entry_header to show that they 'also'
block speculative execution
xen/common/grant_ta
the gnttab_grow_table function
call.
* gnttab_get_shared_frame: block_speculation in
gnttab_get_status_frame_mfn blocks accesses
* gnttab_usage_print: cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
On 5/23/19 16:17, Jan Beulich wrote:
On 21.05.19 at 09:45, wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative out-of-bound accesses, we
>> use th
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h | 6 --
1 file changed, 4
array protection, or multiple accesses in a
row. To protect these, an lfence instruction is placed between the
actual range check and the access via the newly introduced macro
block_speculation.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
different options allow to control the level of protection vs the
slowdown the addtional lfence instructions would introduce. The default
value is set to protecting both branches.
For non-x86 platforms, the protection is disabled by default.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/Kconfig
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
unintrusive code change. During performance testing, we did not
notice performance effects.
Signed-off-by: Norbert Manthey
---
xen/include/xen/nospec.h | 15 +++
xen/include/xen/sched.h | 5 +++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/nospec.h
-off-by: Norbert Manthey
---
xen/common/pdx.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/* Parameters for PFN/MADDR
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/hvm.c | 27 ++-
xen/include/xen/nospec.h | 6 ++
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/vioapic.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
function for guest specified addresses that should
be used for hpet operations.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/hpet.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/xen
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/common/event_channel.c | 25
array_index_nospec macro, we replace the variable with the
constant to be propagated instead.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
xen/arch/x86/cpuid.c | 15 ---
1 file changed, 8 insertions(+), 7
ading. This combination of features is added
to the features that activate the alternative.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/include/xen/nospec.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
On 1/23/19 14:20, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
>> --- a/xen/include/xen/nospec.h
>> +++ b/xen/include/xen/nospec.h
>> @@ -58,6 +58,21 @@ static inline unsigned long
>> array_index_mask_nospec(unsigned long index,
>> (typeof(_i)) (_i & _mask);
On 1/23/19 14:18, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
>> This commit introduces the configuration option L1TF_LFENCE that allows
>> to control the implementation of the protection of privilege checks via
>> lfence instructions. The following four alternatives are provided:
>>
>>
On 1/23/19 15:45, Jan Beulich wrote:
>>>> On 23.01.19 at 14:44, wrote:
>> On 23/01/2019 13:39, Jan Beulich wrote:
>>>>>> On 23.01.19 at 14:24, wrote:
>>>> On 23/01/2019 11:51, Norbert Manthey wrote:
>>>>> --- a/xen/include/xen/nospe
On 1/24/19 17:56, Jan Beulich wrote:
On 23.01.19 at 12:57, wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -368,8 +368,14 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
>> evtchn_port_t port)
>> if ( virq_is_global(virq) && (vcpu != 0) )
>>
On 1/25/19 11:14, Jan Beulich wrote:
On 24.01.19 at 22:29, wrote:
>> Worse is the "evaluate condition, stash result, fence, use variable"
>> option, which is almost completely useless. If you work out the
>> resulting instruction stream, you'll have a conditional expression
>> calculated dow
On 1/24/19 23:29, Andrew Cooper wrote:
> On 23/01/2019 11:57, Norbert Manthey wrote:
>> While the lfence instruction was added for all x86 platform in the
>> beginning, it's useful to not block platforms that are not affected
>> by the L1TF vulnerability. Therefore, the
On 1/25/19 14:09, Jan Beulich wrote:
On 25.01.19 at 11:50, wrote:
>> On 1/25/19 11:14, Jan Beulich wrote:
>> On 24.01.19 at 22:29, wrote:
Worse is the "evaluate condition, stash result, fence, use variable"
option, which is almost completely useless. If you work out the
r
On 1/28/19 08:35, Jan Beulich wrote:
On 27.01.19 at 21:28, wrote:
>> On 1/25/19 14:09, Jan Beulich wrote:
>> On 25.01.19 at 11:50, wrote:
On 1/25/19 11:14, Jan Beulich wrote:
On 24.01.19 at 22:29, wrote:
>> Worse is the "evaluate condition, stash result, fence, use var
On 1/28/19 09:24, Jan Beulich wrote:
On 28.01.19 at 08:56, wrote:
>> On 1/28/19 08:35, Jan Beulich wrote:
>> On 27.01.19 at 21:28, wrote:
On 1/25/19 14:09, Jan Beulich wrote:
On 25.01.19 at 11:50, wrote:
>> On 1/25/19 11:14, Jan Beulich wrote:
>> On 24.01.19 at
On 1/25/19 17:34, Jan Beulich wrote:
On 23.01.19 at 12:57, wrote:
>> @@ -66,6 +67,9 @@ static struct hvm_vioapic *gsi_vioapic(const struct domain
>> *d,
>> {
>> unsigned int i;
>>
>> +/* Make sure the compiler does not optimize the initialization */
>> +OPTIMIZER_HIDE_VAR(pin
On 1/28/19 12:12, Jan Beulich wrote:
On 28.01.19 at 12:03, wrote:
>> On 1/25/19 17:34, Jan Beulich wrote:
>> On 23.01.19 at 12:57, wrote:
@@ -212,7 +217,12 @@ static void vioapic_write_redirent(
struct hvm_irq *hvm_irq = hvm_domain_irq(d);
union vioapic_redir_ent
On 1/24/19 22:05, Andrew Cooper wrote:
> On 23/01/2019 11:51, Norbert Manthey wrote:
>> Dear all,
>>
>> This patch series attempts to mitigate the issue that have been raised in the
>> XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
>>
On 1/23/19 14:37, Jan Beulich wrote:
On 23.01.19 at 12:51, wrote:
>> @@ -1268,7 +1272,8 @@ unmap_common(
>> }
>>
>> smp_rmb();
>> -map = &maptrack_entry(lgt, op->handle);
>> +map = &maptrack_entry(lgt, array_index_nospec(op->handle,
>> +
On 1/28/19 16:09, Jan Beulich wrote:
On 28.01.19 at 15:45, wrote:
>> On 1/23/19 14:37, Jan Beulich wrote:
>> On 23.01.19 at 12:51, wrote:
@@ -2223,7 +2231,8 @@ gnttab_transfer(
okay = gnttab_prepare_for_transfer(e, d, gop.ref);
spin_lock(&e->page_alloc_lo
On 1/29/19 10:46, Jan Beulich wrote:
>>>> Norbert Manthey 01/29/19 9:35 AM >>>
>> I am aware that both version use the same base array, and access it via
>> different macros, which essentially partition the array based on the
>> size of the respective struct
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/common/event_channel.c | 25
. Currently,
the problematic callers are the functions vioapic_irq_positive_edge and
vioapic_get_trigger_mode.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/vioapic.c | 24
1 file changed, 20 insertions
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/hvm.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
#include
#include
via alterantive patching.
Introducing the lfence instructions catches a lot of potential leaks with
a simple unintrusive code change. During performance testing, we did not
notice performance effects.
Signed-off-by: Norbert Manthey
---
xen/include/xen/nospec.h | 28
1
"X86_FEATURE_SC_L1TF_VULN" is introduced. This feature
is used to patch the lfence instruction into the arch_barrier_nospec_true
function. The feature is enabled only if L1TF vulnerable hardware is
detected and the command line option does not prevent using this feature.
Signed-off-by: Norbert Manthey
, the CPU assumes a returned value and continues the
execution.
In case an is_control_domain check is bypassed, for example during a
hypercall, data that should only be accessible by the control domain could
be loaded into the cache.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h | 6 --
1 file changed, 4
array protection, or multiple accesses in a
row. To protect these, a nospec barrier is placed between the actual
range check and the access via the block_speculation macro.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
xen/common
-off-by: Norbert Manthey
---
xen/common/pdx.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
/* Parameters for PFN/MADDR
On 1/29/19 16:11, Jan Beulich wrote:
>>>> On 29.01.19 at 14:47, wrote:
>> On 1/29/19 10:46, Jan Beulich wrote:
>>>>>> Norbert Manthey 01/29/19 9:35 AM >>>
>>>> I am aware that both version use the same base array, and access it via
>
On 1/31/19 16:05, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> --- a/xen/common/event_channel.c
>> +++ b/xen/common/event_channel.c
>> @@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
>> evtchn_port_t port)
>> if ( (virq < 0) || (virq >= ARRAY_SIZE(v->virq_to_e
ou add
> initializers everywhere, clarifying in the description that it's "just
> in case" for the two currently safe ones?
I will add the other initialization and update the commit message.
>
>> This commit is part of the SpectreV1+L1TF mitigation patch series.
>>
On 1/31/19 17:19, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> There are multiple arrays in the HVM interface that are accessed
>> with indices that are provided by the guest. To avoid speculative
>> out-of-bound accesses, we use the array_index_nospec macro.
>>
>> When blocking specula
On 2/1/19 09:23, Jan Beulich wrote:
On 31.01.19 at 21:02, wrote:
>> On 31/01/2019 16:19, Jan Beulich wrote:
@@ -4104,6 +4108,12 @@ static int hvmop_set_param(
if ( a.index >= HVM_NR_PARAMS )
return -EINVAL;
+/*
+ * Make sure the guest cont
On 7/18/19 14:09, Jan Beulich wrote:
> On 12.07.2019 10:51, Norbert Manthey wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative
speculative hardening effort.
Best,
Norbert
Norbert Manthey (2):
common/grant_table: harden bound accesses
common/grant_table: harden version dependent accesses
xen/common/grant_table.c | 107 +--
1 file changed, 75 insertions(+), 32 deletions
speculation.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v3: Drop condition to not fix defects in commit message.
Copy in reviewed-by.
xen/common/grant_table.c | 72 ++--
1
the
gnttab_grow_table function call.
* gnttab_usage_print: cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
xen/common/grant_table.c | 37 +
1 file changed, 25 inserti
On 7/30/19 15:38, Jan Beulich wrote:
> On 30.07.2019 15:15, Norbert Manthey wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is used as index for memory loads after bound
>> checks have been done. To avoid speculative
A pointer mismatch has been reported when compiling with the
compiler goto-gcc of the bounded model checker CBMC.
Fixes: 9a779e4f (Implement SVM specific part for Nested Virtualization)
Signed-off-by: Norbert Manthey
---
xen/arch/x86/hvm/svm/svm.c | 2 +-
1 file changed, 1 insertion(+), 1
On 2/1/19 15:08, Jan Beulich wrote:
On 01.02.19 at 14:45, wrote:
>> On 1/31/19 16:05, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -365,11 +365,16 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
On 1/31/19 17:35, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> @@ -1942,6 +1942,12 @@ Irrespective of Xen's setting, the feature is
>> virtualised for HVM guests to
>> use. By default, Xen will enable this mitigation on hardware believed to
>> be
>> vulnerable to L1TF.
>>
>> +On
gt;
>> Introducing the lfence instructions catches a lot of potential leaks with
>> a simple unintrusive code change. During performance testing, we did not
>> notice performance effects.
>>
>> Signed-off-by: Norbert Manthey
> Looks okay to me now, but I
(Implement SVM specific part for Nested Virtualization)
Signed-off-by: Norbert Manthey
---
Notes:
v2: keep type, use local variable in function call and
xen/arch/x86/hvm/svm/svm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm
On 2/5/19 15:43, Jan Beulich wrote:
On 05.02.19 at 15:23, wrote:
>> On 1/31/19 17:35, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
@@ -1942,6 +1942,12 @@ Irrespective of Xen's setting, the feature is
>> virtualised for HVM guests to
use. By default, Xen will enable thi
From: Norbert Manthey
In the early steps of compilation, the asm header files are created, such
as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
assembly file arch/$(TARGET_ARCH)/asm-offsets.s, which is generated
before. Depending on the used toolchain, there might be
On 2/6/19 15:52, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> @@ -963,6 +965,9 @@ map_grant_ref(
>> PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
>> op->ref, rgt->domain->domain_id);
>>
>> +/* Make sure the above check is not bypassed s
On 2/6/19 16:03, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> @@ -908,10 +909,10 @@ void watchdog_domain_destroy(struct domain *d);
>> *(that is, this would not be suitable for a driver domain)
>> * - There is never a reason to deny the hardware domain access to this
>> */
>>
On 2/6/19 16:25, Jan Beulich wrote:
On 29.01.19 at 15:43, wrote:
>> @@ -33,10 +34,10 @@ unsigned long __read_mostly
>> pdx_group_valid[BITS_TO_LONGS(
>>
>> bool __mfn_valid(unsigned long mfn)
>> {
>> -return likely(mfn < max_page) &&
>> - likely(!(mfn & pfn_hole_mask)) &&
>
On 2/6/19 17:08, Jan Beulich wrote:
On 06.02.19 at 16:39, wrote:
>> On 2/6/19 16:25, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
@@ -33,10 +34,10 @@ unsigned long __read_mostly
pdx_group_valid[BITS_TO_LONGS(
bool __mfn_valid(unsigned long mfn)
{
On 2/6/19 16:53, Jan Beulich wrote:
On 06.02.19 at 16:06, wrote:
>> On 2/6/19 15:52, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
@@ -963,6 +965,9 @@ map_grant_ref(
PIN_FAIL(unlock_out, GNTST_bad_gntref, "Bad ref %#x for d%d\n",
op->ref, rg
On 2/6/19 17:01, Jan Beulich wrote:
On 06.02.19 at 16:36, wrote:
>> On 2/6/19 16:03, Jan Beulich wrote:
>> On 29.01.19 at 15:43, wrote:
@@ -908,10 +909,10 @@ void watchdog_domain_destroy(struct domain *d);
*(that is, this would not be suitable for a driver domain)
On 2/7/19 10:50, Norbert Manthey wrote:
> On 2/6/19 16:53, Jan Beulich wrote:
>>>>> On 06.02.19 at 16:06, wrote:
>>> On 2/6/19 15:52, Jan Beulich wrote:
>>>>>>> On 29.01.19 at 15:43, wrote:
>>>>> @@ -963,6 +965,9 @@ map_grant_ref(
On 2/7/19 15:00, Jan Beulich wrote:
>>>> On 07.02.19 at 11:20, wrote:
>> On 2/7/19 10:50, Norbert Manthey wrote:
>>> On 2/6/19 16:53, Jan Beulich wrote:
>>>>>>> On 06.02.19 at 16:06, wrote:
>>>>> On 2/6/19 15:52, Jan Beulich wrote:
&
Dear all,
This patch series attempts to mitigate the issue that have been raised in the
XSA-289 (https://xenbits.xen.org/xsa/advisory-289.html). To block speculative
execution on Intel hardware, an lfence instruction is required to make sure
that selected checks are not bypassed. Speculative out-o
Guests can issue event channel interaction with guest specified data.
To avoid speculative out-of-bound accesses, we use the nospec macros,
or the domain_vcpu function.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
Notes:
v6: drop vcpu
Signed-off-by: Norbert Manthey
---
Notes:
v6: Match commit message with code
Fix nospec bound in hvm_msr_read_intercept
xen/arch/x86/hvm/hvm.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a
.
This commit is part of the SpectreV1+L1TF mitigation patch series.
Signed-off-by: Norbert Manthey
---
Notes:
v6: Explain initialization in commit message
Initialize pin in all 4 functions that call gsi_vioapic
Fix space in comment
xen/arch/x86/hvm/vioapic.c | 28
When checking for being an hvm domain, or PV domain, we have to make
sure that speculation cannot bypass that check, and eventually access
data that should not end up in cache for the current domain type.
Signed-off-by: Norbert Manthey
---
xen/include/xen/sched.h | 6 --
1 file changed, 4
mitigation patch series.
Signed-off-by: Norbert Manthey
---
Notes:
v6: Explain version 1 vs version 2 case in commit message
Protect grant table version checks
Use block_speculation in map_grant_ref instead of updating op->ref
Move evaluate_nospec closer to the okay variable
change. During performance testing, we did not
notice performance effects.
Signed-off-by: Norbert Manthey
---
Notes:
v6: Introduce asm nospec.h files
Check CONFIG_HVM consistently
Extend commit message to explain CONFIG_HVM and new files
Fix typos in commit message
xen
ing is not considered when automatically enabling
adding the lfence instruction, because platforms without hyperthreading
can still be vulnerable to L1TF in case the L1 cache is not flushed
properly.
Signed-off-by: Norbert Manthey
---
Notes:
v6: Move disabling l1tf-barrier into spec-ctrl=no
, the CPU assumes a returned value and continues the
execution.
In case an is_control_domain check is bypassed, for example during a
hypercall, data that should only be accessible by the control domain could
be loaded into the cache.
Signed-off-by: Norbert Manthey
---
Notes:
v6: Drop nospec.h
-off-by: Norbert Manthey
---
Notes:
v6: Add array_index_nospec to test_bit call
xen/common/pdx.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/xen/common/pdx.c b/xen/common/pdx.c
--- a/xen/common/pdx.c
+++ b/xen/common/pdx.c
@@ -18,6 +18,7 @@
#include
As XTF allows to write tests that interact with the hypervisor, we would like
to use this capability to implement micro benchmarks, so that we can measure
the performance impact of modifications to the hypervisor.
Signed-off-by: Norbert Manthey
---
build/common.mk | 2 +-
xtf-runner | 2
Dear all,
I added a perf category to XTF, and added functions to measure time in the
guest. Finally, I added a first micro benchmark that measures the time to
call a specified hypercall, and print the average time the hypercall takes.
The added category should be useful to implement further micro
A first simple test is to call a hypercall in a tight loop. To measure
implementation aspects of the hypervisor, we picked a hypercall that
is not implemented and hence results in a no-op, namely the hypercall
mmuext_op with the command MMUEXT_MARK_SUPER.
Signed-off-by: Norbert Manthey
To measure how long a certain interaction takes, we need time
primitives. This commit introduces these primitives, so that
future tests can use the gettimeofday function to retrieve the
current time.
Signed-off-by: Paul Semel
Signed-off-by: Norbert Manthey
---
build/files.mk | 1
processing the output further.
This format is, where average-time provides ns with ps granularity:
perf test_name ns
Signed-off-by: Norbert Manthey
---
common/time.c | 36
include/xtf/time.h | 8 +++-
2 files changed, 43 insertions(+), 1
On 2/6/19 16:10, Jan Beulich wrote:
>>>> On 06.02.19 at 15:09, wrote:
>> From: Norbert Manthey
>>
>> In the early steps of compilation, the asm header files are created, such
>> as include/asm-$(TARGET_ARCH)/asm-offsets.h. These files depend on the
>
On 2/12/19 14:25, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -3453,7 +3456,8 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t
>> *msr_content)
>> if ( (index / 2) >=
>> MASK_EXTR(v->arch.hvm.mtrr.mtrr_cap, MTRRcap_VCNT) )
>> goto gp_faul
On 2/12/19 14:08, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -813,6 +817,13 @@ int set_global_virq_handler(struct domain *d, uint32_t
>> virq)
>>
>> if (virq >= NR_VIRQS)
>> return -EINVAL;
>> +
>> + /*
>> +* Make sure the guest controlled value virq is boun
On 2/12/19 14:16, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> When interacting with io apic, a guest can specify values that are used
>> as index to structures, and whose values are not compared against
>> upper bounds to prevent speculative out-of-bound accesses. This change
>> preven
On 2/12/19 14:50, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef _ASM_X
On 2/12/19 15:12, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,39 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef _ASM_X
percall, data that should only be accessible by the control domain could
>> be loaded into the cache.
>>
>> Signed-off-by: Norbert Manthey
>>
>> ---
>>
>> Notes:
>> v6: Drop nospec.h include
> And this was because of what? I think it is good pr
On 2/12/19 15:31, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -33,10 +34,11 @@ unsigned long __read_mostly
>> pdx_group_valid[BITS_TO_LONGS(
>>
>> bool __mfn_valid(unsigned long mfn)
>> {
>> -return likely(mfn < max_page) &&
>> - likely(!(mfn & pfn_hole_mask)) &&
On 2/12/19 15:14, Jan Beulich wrote:
On 12.02.19 at 15:05, wrote:
>> On 2/12/19 14:25, Jan Beulich wrote:
>> On 08.02.19 at 14:44, wrote:
@@ -4104,6 +4108,12 @@ static int hvmop_set_param(
if ( a.index >= HVM_NR_PARAMS )
return -EINVAL;
+/*
>>
ction, because platforms without hyperthreading
>> can still be vulnerable to L1TF in case the L1 cache is not flushed
>> properly.
>>
>> Signed-off-by: Norbert Manthey
>>
>> ---
>>
>> Notes:
>> v6: Move disabling l1tf-barrier int
On 2/13/19 12:50, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> Guests can issue grant table operations and provide guest controlled
>> data to them. This data is also used for memory loads. To avoid
>> speculative out-of-bound accesses, we use the array_index_nospec macro
>> where appli
On 2/15/19 09:55, Jan Beulich wrote:
On 15.02.19 at 09:05, wrote:
>> On 2/12/19 15:14, Jan Beulich wrote:
>> On 12.02.19 at 15:05, wrote:
On 2/12/19 14:25, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> @@ -4104,6 +4108,12 @@ static int hvmop_set_param(
>>
On 2/15/19 11:34, Jan Beulich wrote:
On 15.02.19 at 10:55, wrote:
>> On 2/13/19 12:50, Jan Beulich wrote:
>> On 08.02.19 at 14:44, wrote:
Guests can issue grant table operations and provide guest controlled
data to them. This data is also used for memory loads. To avoid
sp
On 2/15/19 12:46, Jan Beulich wrote:
On 15.02.19 at 11:50, wrote:
>> On 2/15/19 09:55, Jan Beulich wrote:
>> On 15.02.19 at 09:05, wrote:
On 2/12/19 15:14, Jan Beulich wrote:
On 12.02.19 at 15:05, wrote:
>> On 2/12/19 14:25, Jan Beulich wrote:
>> On 08.02.19 at
On 2/18/19 17:08, Jan Beulich wrote:
On 18.02.19 at 14:49, wrote:
>> On 2/15/19 11:34, Jan Beulich wrote:
>> On 15.02.19 at 10:55, wrote:
On 2/13/19 12:50, Jan Beulich wrote:
On 08.02.19 at 14:44, wrote:
>> Guests can issue grant table operations and provide guest cont
only one access needs to be protected.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
explain preferred use of internal data in commit message
drop update in set_global_virq_handler
hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
fix comment typo
drop 'guest controlled' from commit message
xen/arch/x86/hvm/vioapic.c | 28 ++--
1 file changed, 22 insertions(+), 6
1 - 100 of 198 matches
Mail list logo
