This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
--- a/xen/arch/x86
On 2/11/22 11:34, Jan Beulich wrote:
> On 11.02.2022 08:23, Norbert Manthey wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -609,7 +609,7 @@ void __init init_guest_cpuid(void)
>> bool recheck_cpu_features(unsigned int cpu)
>> {
>>
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
---
xen/arch/x86/cpuid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
--- a/xen/arch/x86
On 3/3/21 5:13 PM, Ian Jackson wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> Norbert Manthey writes ("[PATCH XENSTORE v1 09/10
On 3/2/21 6:15 AM, Jürgen Groß wrote:
> On 26.02.21 16:36, Andrew Cooper wrote:
>> On 26/02/2021 14:41, Norbert Manthey wrote:
>>> The read value could be larger than a signed 32bit integer. As -1 is
>>> used as error value, we should not rely on using the full 32 bi
On 2/26/21 3:53 PM, Julien Grall wrote:
> Hi Norbert,
>
> On 26/02/2021 14:41, Norbert Manthey wrote:
>> In case of a failure deep in the call tree, we might return NULL as the
>> value of the domain. In that case, error out instead of dereferencing
>> the N
In case of a failure deep in the call tree, we might return NULL as the
value of the domain. In that case, error out instead of dereferencing
the NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert
ould still be
fixed to not result in a NULL pointer dereference.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/libs/store/xs.c | 3 +
, this change only covers the corner case to make
sure we stay in the 32 bit range.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools
) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
--- a/tools/xenstore/xenstored_core.c
+++ b
From: Michael Kurth
In case of allocation error, we should not dereference the obtained
NULL pointer.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Michael Kurth
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas
Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.c | 4
1 file changed, 4 insertions(+)
diff --git a/tools/xenstore/xenstored_core.c b/tools/xenstore/xenstored_core.c
was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstore_client.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/xenstore
When passing format strings to the trace function, allow gcc to analyze
those and warn on issues.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore/xenstored_core.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools
In case of allocation error, we should not dereference the obtained
NULL pointer. Hence, fail early.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien
Use the correct format specifier for unsigned values. Additionally, a
cast was dropped, as the format specifier did not require it anymore.
This was reported by analysis with cppcheck.
Signed-off-by: Norbert Manthey
Reviewed-by: Thomas Friebel
Reviewed-by: Julien Grall
---
tools/xenstore
Dear all,
we have been running some code analysis tools on the xenstore code, and triaged
the results. This series presents the robustness fixes we identified.
Best,
Norbert
Michael Kurth (1):
xenstore: add missing NULL check
Norbert Manthey (9):
xenstore: add missing NULL check
xenstore
between the get and set operations, function
hvmop_set_param is made static.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
Release-Acked-by: Ian Jackson
---
v4: * add 'static' attribute to hvmop_set_param
* drop introduced bound
On 2/12/21 11:04 AM, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 11.02.2021 21:46, Norbert Manthey wrote:
>>
On 2/9/21 3:21 PM, Jan Beulich wrote:
> On 09.02.2021 14:56, Norbert Manthey wrote:
>> On 2/9/21 2:45 PM, Jan Beulich wrote:
>>> On 09.02.2021 14:41, Norbert Manthey wrote:
>>>> On 2/9/21 10:40 AM, Jan Beulich wrote:
>>>>> On 08.02.2021 20:47, Norbert
On 2/9/21 2:45 PM, Jan Beulich wrote:
> On 09.02.2021 14:41, Norbert Manthey wrote:
>> On 2/9/21 10:40 AM, Jan Beulich wrote:
>>> On 08.02.2021 20:47, Norbert Manthey wrote:
>>>> On 2/8/21 3:21 PM, Jan Beulich wrote:
>>>>> On 05.02.2021 21:39, Norb
On 2/9/21 10:40 AM, Jan Beulich wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> On 08.02.2021 20:47, Norbert Manthey wrote:
>
to leak hvm parameter values of
other domains.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
Release-Acked-by: Ian Jackson
---
v3: * rephrased commit message to better explain code relocation
* added release-acked
xen/arch/x86
On 2/8/21 3:21 PM, Jan Beulich wrote:
> On 05.02.2021 21:39, Norbert Manthey wrote:
>> To prevent leaking HVM params via L1TF and similar issues on a
>> hyperthread pair, let's load values of domains as late as possible.
>>
>> Furthermore, speculative barriers are re-
.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
---
v2: Add another speculative blocker, which protects the return code check
of the function hvm_allow_set_param.
xen/arch/x86/hvm/hvm.c | 19 +++
1 file changed, 15
.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reported-by: Hongyan Xia
---
xen/arch/x86/hvm/hvm.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c
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 | 76 ++
include/xtf/time.h | 15 +
2 files changed, 91 insertions
micro benchmarks. I
already implemented a few more that I will publish once the environment is
agreed on.
Best,
Norbert
Norbert Manthey (4):
categories: add benchmark
time: add stubs
time: provide measurement template
perf: measure MMUEXT_MARK_SUPER test
build/common.mk
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
for 1000 calls to the hypercall,
and next calculates the number of calls to take about 5 minutes.
Signed-off-by: Norbert Manthey
Reviewed-by: Bjoern Doebel
---
tests/perf-PV-MMUEXT_MARK_SUPER-noop/Makefile | 9 +++
tests/perf-PV-MMUEXT_MARK_SUPER-noop/main.c | 80 +++
2 files
for tests of this kind.
Signed-off-by: Norbert Manthey
---
build/common.mk | 2 +-
xtf-runner | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build/common.mk b/build/common.mk
--- a/build/common.mk
+++ b/build/common.mk
@@ -1,4 +1,4 @@
-ALL_CATEGORIES := special
On 10/29/19 15:16, Andrew Cooper wrote:
> On 29/10/2019 14:03, Jan Beulich wrote:
>> On 29.10.2019 14:46, Andrew Cooper wrote:
>>> If this patch series does not agreement, I will unblock livepatching on
>>> 4.13 by committing the v2 patch which causes BRANCH_HARDEN to depend on
>>> BROKEN and
On 10/28/19 18:05, Andrew Cooper wrote:
> On 25/10/2019 22:56, Norbert Manthey wrote:
>> On 10/25/19 17:40, Jan Beulich wrote:
>>> On 25.10.2019 17:27, Andrew Cooper wrote:
>>>> On 25/10/2019 13:34, Jan Beulich wrote:
>>>>> On 25.10.2019 14:10
On 10/25/19 17:40, Jan Beulich wrote:
> On 25.10.2019 17:27, Andrew Cooper wrote:
>> On 25/10/2019 13:34, Jan Beulich wrote:
>>> On 25.10.2019 14:10, Andrew Cooper wrote:
The two choices to unblock 4.13 are this patch, or the previous version
which made CONFIG_HARDEN_BRANCH depend on
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
ses in 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
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
of the 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
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
ses in 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/11/19 14:34, Jan Beulich wrote:
> On 10.07.2019 14:54, 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
ses in 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
---
Notes:
v2: Add block_speculation to gnttab_populate_status_frames and
gnttab_unpopulate_status_fra
equals
two might not hold under speculation.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v2: Mention version based blocking for upcoming commit
Introduce local variable as op->ref replacement
Use array_nospec_in
of the 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 | 115 ---
1 file changed, 79 insertions(+), 36 deletions
On 7/10/19 05:12, Jan Beulich wrote:
> On 08.07.2019 15:53, Norbert Manthey wrote:
>> On 5/23/19 17:01, Jan Beulich wrote:
>>>>>> On 21.05.19 at 09:45, wrote:
>>>> * gnttab_set_version: all accessible data is allocated for both versions
>>> This
On 7/10/19 05:04, Jan Beulich wrote:
> On 08.07.2019 14:58, Norbert Manthey wrote:
>> On 5/24/19 13:10, Jan Beulich wrote:
>>>>>> On 24.05.19 at 11:54, wrote:
>>>> On 5/23/19 16:17, Jan Beulich wrote:
>>>>>>>> On 21.05.19 at 09:45,
On 5/23/19 17:01, 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. Depending on the grant table version, the
>> size of
Sorry for the late reply. I try to pick up where we left the discussion
the last time.
On 5/24/19 13:10, Jan Beulich wrote:
On 24.05.19 at 11:54, wrote:
>> 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
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
ing 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:
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_table.c | 43
of 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
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
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
On 4/24/19 20:10, Andrew Cooper wrote:
> c/s f8303458 restricted speculative access for do_vcpu_op(), but neglected its
> compat counterpart, which is reachable by guests using the 32bit ABI.
>
> Make an identical adjustment.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
On 4/5/19 17:34, Andrew Cooper wrote:
> On 14/03/2019 12:50, Norbert Manthey wrote:
>> 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 th
l leaks with
>> a simple unintrusive code change. During performance testing, we did not
>> notice performance effects.
>>
>> This is part of the speculative hardening effort.
>>
>> Signed-off-by: Norbert Manthey
>> Acked-by: Julien Grall
> I did give my ack on v
the
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
When issuing a vcpu_op hypercall, guests have control over the
vcpuid variable. In the old code, this allowed to perform
speculative out-of-bound accesses. To block this, we make use
of the domain_vcpu function.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
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.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked
memory accesses
are protected in gnttab_get_status_frame_mfn
* gnttab_usage_print, as this function cannot be triggered by the guest
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v10: extended commit message with explanation when
that the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Jan Beulich
---
xen/arch/x86/hvm/hvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
--- a/xen
-by: Norbert Manthey
Acked-by: Jan Beulich
---
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10 +913,10 @@ void
code change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
xen/include/asm-arm/nospec.h | 25 +
xen/include/asm-x86/nospec.h | 39
is missing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c | 17 +++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/s
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
On 3/5/19 17:38, Jan Beulich wrote:
On 27.02.19 at 17:13, wrote:
>> Speculative execution is not blocked in case one of the following
>> properties is true:
>> - path cannot be triggered by the guest
>> - path does not return to the guest
>> - path does not result in an out-of-bound
On 2/28/19 11:00, Jan Beulich wrote:
On 27.02.19 at 14:01, wrote:
>> On 2/25/19 17:46, Jan Beulich wrote:
>>> I would really like to ask that I (or someone else) don't need to
>>> go through and list remaining version checks again - after all I
>>> had done so for v6 already, and I didn't go
that the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Jan Beulich
---
Notes:
v9: fixed inline comments
added acked-by
xen/arch/x86/hvm/hvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
the
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
of
protective mechanisms in case a potential speculative out-of-bound
access matches all the above properties.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v8: extended commit message with reason when to block speculation
fix order assert_unreachable
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.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked
-by: Norbert Manthey
Acked-by: Jan Beulich
---
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10 +913,10 @@ void
code change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
Notes:
v9: fixed indentation (ARM)
dropped CONFIG_HVM in evaluate_nospec
dropped cast
is missing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c | 17 +++--
xen/include/asm-x86/cpufeatures.h | 1 +
xen/include/asm-x86/s
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-of-bound
On 2/25/19 17:46, Jan Beulich wrote:
On 25.02.19 at 14:34, wrote:
>> @@ -634,14 +649,24 @@ static unsigned int nr_grant_entries(struct
>> grant_table *gt)
>> case 1:
>> BUILD_BUG_ON(f2e(INITIAL_NR_GRANT_FRAMES, 1) <
>> GNTTAB_NR_RESERVED_ENTRIES);
>> +
>>
On 2/25/19 16:59, Jan Beulich wrote:
On 25.02.19 at 14:34, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4109,6 +4109,11 @@ static int hvmop_set_param(
>> if ( a.index >= HVM_NR_PARAMS )
>> return -EINVAL;
>>
>> +/*
>> + * Make sure the
On 2/25/19 16:54, Jan Beulich wrote:
On 25.02.19 at 14:34, wrote:
>> Since the L1TF vulnerability of Intel CPUs, loading hypervisor data into
>> L1 cache is problematic, because when hyperthreading is used as well, a
>> guest running on the sibling core can leak this potentially secret data.
that the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v8: drop a.index update before block_speculation
improve comments
xen/arch/x86/hvm/hvm.c | 10 ++
1 file changed, 10 insertions(+)
diff
change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked-by: Julien Grall
---
Notes:
v8: add acked-by
replace macros with inline functions (ARM)
replace macros
is missing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
drop == 0 and exchange != 0 with negation
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/spec_ctrl.c
-by: Norbert Manthey
Acked-by: Jan Beulich
---
Notes:
v8: added acked-by
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -913,10
that only one access needs to be protected.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
drop blank line change
xen/common/event_channel.c | 28 +---
xen/common
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.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
Acked
hardening effort.
Signed-off-by: Norbert Manthey
Reviewed-by: Jan Beulich
---
Notes:
v8: add reviewed-by
xen/arch/x86/hvm/vioapic.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
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
On 2/22/19 14:00, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> @@ -813,6 +817,7 @@ int set_global_virq_handler(struct domain *d, uint32_t
>> virq)
>>
>> if (virq >= NR_VIRQS)
>> return -EINVAL;
>> +
>> if (!virq_is_global(virq))
>> return -EINVAL;
>>
>
On 2/22/19 16:08, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> @@ -226,10 +228,18 @@ nr_maptrack_frames(struct grant_table *t)
>> static grant_entry_header_t *
>> shared_entry_header(struct grant_table *t, grant_ref_t ref)
>> {
>> -if ( t->gt_version == 1 )
>> +switch (
On 2/22/19 14:17, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> --- /dev/null
>> +++ b/xen/include/asm-x86/nospec.h
>> @@ -0,0 +1,38 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright 2018 Amazon.com, Inc. or its affiliates. All Rights Reserved.
>> */
>> +
>> +#ifndef
On 2/22/19 15:39, Jan Beulich wrote:
On 21.02.19 at 09:16, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -4109,6 +4109,13 @@ static int hvmop_set_param(
>> if ( a.index >= HVM_NR_PARAMS )
>> return -EINVAL;
>>
>> +/*
>> + * Make sure the
, speculative
execution might perform out-of-bound accesses of version 2 while
the table is actually using version 1. Hence, speculation is prevented
when accessing memory based on the grant table version.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes
that the update is visible in the architectural state.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: add speculative hardening to commit message
add lfence to a.index updates (other parts of that commit have
been committed already
the
evaluate_nospec macro. To make the protection generic, we do not
introduce the lfence instruction for this single check, but add it to
the mfn_valid function. This way, other potentially problematic accesses
are protected as well.
This is part of the speculative hardening effort.
Signed-off-by: Norbert
-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
xen/include/xen/sched.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
change. During performance testing, we did not
notice performance effects.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit messate
drop system.h include
drop arch prefix
add outer brackets
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.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
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), namely to avoid
touching memory from the hypervisor speculatively that would not be touched
without speculation. To block speculative execution on Intel
is missing.
This is part of the speculative hardening effort.
Signed-off-by: Norbert Manthey
---
Notes:
v7: mention speculative hardening in commit message
consider smt and l1dflush in auto setting for l1tf-barrier
docs/misc/xen-command-line.pandoc | 14 ++
xen/arch/x86/s
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 deletions
1 - 100 of 191 matches
Mail list logo
